RFC3540 日本語訳

3540 Robust Explicit Congestion Notification (ECN) Signaling withNonces. N. Spring, D. Wetherall, D. Ely. June 2003. (Format: TXT=30081 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                          N. Spring
Request for Comments: 3540                                  D. Wetherall
Category: Experimental                                            D. Ely
                                                University of Washington
                                                               June 2003

コメントを求めるワーキンググループN.春の要求をネットワークでつないでください: 3540年のD.Wetherallカテゴリ: 実験的なD.イーリーワシントン大学2003年6月

             Robust Explicit Congestion Notification (ECN)
                         Signaling with Nonces

一回だけで合図する体力を要している明白な混雑通知(電子証券取引ネットワーク)

Status of this Memo

このMemoの状態

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

Abstract

要約

   This note describes the Explicit Congestion Notification (ECN)-nonce,
   an optional addition to ECN that protects against accidental or
   malicious concealment of marked packets from the TCP sender.  It
   improves the robustness of congestion control by preventing receivers
   from exploiting ECN to gain an unfair share of network bandwidth.
   The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in
   the ECN field of the IP header, and requires a flag in the TCP
   header.  It is computationally efficient for both routers and hosts.

この注意はExplicit Congestion Notification(電子証券取引ネットワーク)一回だけ(TCP送付者から著しいパケットの偶然の、または、悪意がある隠すことから守る電子証券取引ネットワークへの任意の追加)について説明します。 それは、ネットワーク回線容量の不公平なシェアを獲得するのに電子証券取引ネットワークを利用するのからの受信機を防ぐことによって、輻輳制御の丈夫さを改良します。 電子証券取引ネットワーク-一回だけは、IPヘッダーの電子証券取引ネットワーク分野で2の電子証券取引ネットワークできるTransport(ECT)codepointsを使用して、TCPヘッダーで旗を必要とします。 ルータとホストの両方には、それは計算上効率的です。

1.  Introduction

1. 序論

   Statement of Intent

主旨書

      This specification describes an optional addition to Explicit
      Congestion Notification [RFC3168] improving its robustness against
      malicious or accidental concealment of marked packets.  It has not
      been deployed widely.  One goal of publication as an Experimental
      RFC is to be prudent, and encourage use and deployment prior to
      publication in the standards track.  Another consideration is to
      give time for firewall developers to recognize and accept the
      pattern presented by the nonce.  It is the intent of the Transport
      Area Working Group to re-submit this specification as an IETF
      Proposed Standard in the future after more experience has been
      gained.

この仕様は、著しいパケットの悪意があるか偶然の隠すことに対して丈夫さを改良しながら、Explicit Congestion Notification[RFC3168]に任意の添加を説明します。 それは広く配備されていません。 Experimental RFCとしての公表の1つの目標は、慎重であり、公表の前に標準化過程で使用と展開を奨励することです。 別の考慮はファイアウォール開発者が一回だけによって提示されたパターンを認めて、受け入れる時間を与えることです。 それは、より多くの経験の後の未来のIETF Proposed Standardを獲得したのに従ってTransport Area作業部会がこの仕様を再提出する意図です。

Spring, et. al.               Experimental                      [Page 1]

RFC 3540                  Robust ECN Signaling                 June 2003

etスプリング、アル。 電子証券取引ネットワークシグナリング2003年6月に強健な実験的な[1ページ]RFC3540

   The correct operation of ECN requires the cooperation of the receiver
   to return Congestion Experienced signals to the sender, but the
   protocol lacks a mechanism to enforce this cooperation.  This raises
   the possibility that an unscrupulous or poorly implemented receiver
   could always clear ECN-Echo and simply not return congestion signals
   to the sender.  This would give the receiver a performance advantage
   at the expense of competing connections that behave properly.  More
   generally, any device along the path (NAT box, firewall, QOS
   bandwidth shapers, and so forth) could remove congestion marks with
   impunity.

電子証券取引ネットワークの正しい操作は送付者への信号をCongestion Experiencedに返すために受信機の協力を必要としますが、プロトコルはこの協力を実施するメカニズムを欠いています。 これは無遠慮であるか不十分に実行された受信機がいつも電子証券取引ネットワーク-エコーをクリアして、混雑信号を送付者に絶対に返すことができなかった可能性を上げます。 これは礼儀正しく振る舞う競争している接続を犠牲にして性能利点を受信機に与えるでしょう。 より一般に、経路(NAT箱、ファイアウォール、QOS帯域幅整形器など)に沿ったどんな装置も混雑マークを罰を受けずに取り除くかもしれません。

   The above behaviors may or may not constitute a threat to the
   operation of congestion control in the Internet.  However, given the
   central role of congestion control, it is prudent to design the ECN
   signaling loop to be robust against as many threats as possible.  In
   this way, ECN can provide a clear incentive for improvement over the
   prior state-of-the-art without potential incentives for abuse.  The
   ECN-nonce is a simple, efficient mechanism to eliminate the potential
   abuse of ECN.

上の振舞いはインターネットでの輻輳制御の操作への脅威を構成するかもしれません。 しかしながら、輻輳制御の中心的役割を考えて、できるだけ多くの脅威に対して強健になるように電子証券取引ネットワークシグナリング輪を設計するのは慎重です。 このように、電子証券取引ネットワークは乱用に、潜在的誘因なしで最先端の先の上の改良に明確な誘因を提供できます。 電子証券取引ネットワーク-一回だけは電子証券取引ネットワークの潜在的乱用を排除する簡単で、効率的なメカニズムです。

   The ECN-nonce enables the sender to verify the correct behavior of
   the ECN receiver and that there is no other interference that
   conceals marked (or dropped) packets in the signaling path.  The ECN-
   nonce protects against both implementation errors and deliberate
   abuse.  The ECN-nonce:

電子証券取引ネットワーク-一回だけは、送付者が、電子証券取引ネットワーク受信機の正しい動きと、シグナリング経路で著しい(または、落とされる)パケットを隠す他の干渉が全くないことを確かめるのを可能にします。 電子証券取引ネットワーク一回だけは実現誤りと慎重な乱用の両方から守ります。 電子証券取引ネットワーク-一回だけ:

   -  catches a misbehaving receiver with a high probability, and never
      implicates an innocent receiver.

- 高い確率でふらちな事する受信機に間に合って、潔白な受信機を決して巻き込みません。

   -  does not change other aspects of ECN, nor does it reduce the
      benefits of ECN for behaving receivers.

- 電子証券取引ネットワークの他の局面を変えてください、そして、それは、受信機を反応させるために電子証券取引ネットワークの利益を下げません。

   -  is cheap in both per-packet overhead (one TCP header flag) and
      processing requirements.

- パケットあたりの両方の、オーバーヘッド(1個のTCPヘッダー旗)で安く、要件を処理すること。

   -  is simple and, to the best of our knowledge, not prone to other
      attacks.

- 私たちの知識では、簡単であって、他の攻撃に傾向がありません。

   We also note that use of the ECN-nonce has two additional benefits,
   even when only drop-tail routers are used.  First, packet drops
   cannot be concealed from the sender.  Second, it prevents optimistic
   acknowledgements [Savage], in which TCP segments are acknowledged
   before they have been received.  These benefits also serve to
   increase the robustness of congestion control from attacks.  We do
   not elaborate on these benefits in this document.

また、低下テールルータだけが使用されてさえいるとき、私たちは、電子証券取引ネットワーク-一回だけの使用には2つの付加的な利益があることに注意します。 まず最初に、送付者からパケット滴を隠すことができません。 2番目に、それは楽観的な承認[サヴェージ]を防ぎます。(そこでは、それらを受け取る前にTCPセグメントを承認します)。 また、これらの利益は、攻撃から輻輳制御の丈夫さを増加させるのに役立ちます。 私たちは本書ではこれらの利益について詳しく説明しません。

   The rest of this document describes the ECN-nonce.  We present an
   overview followed by detailed behavior at senders and receivers.

このドキュメントの残りは電子証券取引ネットワーク-一回だけについて説明します。 私たちは概観を提示します、続いて、送付者と受信機に詳細な振舞いを提示します。

Spring, et. al.               Experimental                      [Page 2]

RFC 3540                  Robust ECN Signaling                 June 2003

etスプリング、アル。 電子証券取引ネットワークシグナリング2003年6月に強健な実験的な[2ページ]RFC3540

   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]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?

2.  Overview

2. 概観

   The ECN-nonce builds on the existing ECN-Echo and Congestion Window
   Reduced (CWR) signaling mechanism.  Familiarity with ECN [ECN] is
   assumed.  For simplicity, we describe the ECN-nonce in one direction
   only, though it is run in both directions in parallel.

既存の電子証券取引ネットワーク-エコーとCongestion Window Reduced(CWR)シグナル伝達機構の上の電子証券取引ネットワーク-一回だけ体格。 電子証券取引ネットワーク[電子証券取引ネットワーク]への親しみは想定されます。 それは平行な両方の指示に立候補することですが、簡単さのために、私たちは電子証券取引ネットワーク-一回だけについて一方向だけに説明します。

   The ECN protocol for TCP remains unchanged, except for the definition
   of a new field in the TCP header.  As in [RFC3168], ECT(0) or ECT(1)
   (ECN-Capable Transport) is set in the ECN field of the IP header on
   outgoing packets.  Congested routers change this field to CE
   (Congestion Experienced).  When TCP receivers notice CE, the ECE
   (ECN-Echo) flag is set in subsequent acknowledgements until receiving
   a CWR flag.  The CWR flag is sent on new data whenever the sender
   reacts to congestion.

TCPヘッダーとの新しい分野の定義以外に、TCPのための電子証券取引ネットワークプロトコルは変わりがありません。 [RFC3168]のように、ECT(0)かECT(1)(電子証券取引ネットワークできるTransport)が出発しているパケットの上でIPヘッダーの電子証券取引ネットワーク分野で用意ができています。 混雑しているルータはこの分野をCE(混雑Experienced)に変えます。 TCP受信機通知CEであるときに、ECE(電子証券取引ネットワーク-エコー)旗はその後の承認でCWR旗を受けるまで設定されます。 送付者が混雑に反応するときはいつも、新しいデータでCWR旗を送ります。

   The ECN-nonce adds to this protocol, and enables the receiver to
   demonstrate to the sender that segments being acknowledged were
   received unmarked.  A random one-bit value (a nonce) is encoded in
   the two ECT codepoints.  The one-bit sum of these nonces is returned
   in a TCP header flag, the nonce sum (NS) bit.  Packet marking erases
   the nonce value in the ECT codepoints because CE overwrites both ECN
   IP header bits.  Since each nonce is required to calculate the sum,
   the correct nonce sum implies receipt of only unmarked packets.  Not
   only are receivers prevented from concealing marked packets, middle-
   boxes along the network path cannot unmark a packet without
   successfully guessing the value of the original nonce.

電子証券取引ネットワーク-一回だけは、このプロトコルに言い足して、受信機が、承認されるセグメントが受け取られたのを送付者に示すのを可能にします。無印。 無作為の1ビットの値(一回だけ)は2ECT codepointsでコード化されます。 これらの一回だけの1ビットの合計はTCPヘッダー旗、一回だけの合計(NS)ビットで返されます。 CEが両方の電子証券取引ネットワークIPヘッダービットを上書きするので、パケットマークはECT codepointsで一回だけの値を消します。 各一回だけが合計について計算するのに必要であるので、正しい一回だけの合計は無印のパケットだけの領収書を含意します。 首尾よくオリジナルの一回だけの値を推測しないで、受信機が著しいパケットを隠すのが防がれるだけではなく、ネットワーク経路に沿った中央箱はパケットを非マークできません。

   The sender can verify the nonce sum returned by the receiver to
   ensure that congestion indications in the form of marked (or dropped)
   packets are not being concealed.  Because the nonce sum is only one
   bit long, senders have a 50-50 chance of catching a lying receiver
   whenever an acknowledgement conceals a mark.  Because each
   acknowledgement is an independent trial, cheaters will be caught
   quickly if there are repeated congestion signals.

送付者は受信機によって返された、著しい(または、落とされる)パケットの形における混雑指摘が隠されていなかったのを保証した一回だけの合計について確かめることができます。 一回だけの合計が長さ1ビットであるだけであるので、送付者には、承認がマークを隠すときはいつも、横たわっている受信機に間に合うという50-50機会があります。 各承認が独立しているトライアルであるので、繰り返された混雑信号があると、詐欺師はすばやく捕らえられるでしょう。

   The following paragraphs describe aspects of the ECN-nonce protocol
   in greater detail.

以下のパラグラフは詳細によりすばらしい電子証券取引ネットワーク-一回だけプロトコルの局面について説明します。

Spring, et. al.               Experimental                      [Page 3]

RFC 3540                  Robust ECN Signaling                 June 2003

etスプリング、アル。 電子証券取引ネットワークシグナリング2003年6月に強健な実験的な[3ページ]RFC3540

   Each acknowledgement carries a nonce sum, which is the one bit sum
   (exclusive-or, or parity) of nonces over the byte range represented
   by the acknowledgement.  The sum is used because not every packet is
   acknowledged individually, nor are packets acknowledged reliably.  If
   a sum were not used, the nonce in an unmarked packet could be echoed
   to prove to the sender that the individual packet arrived unmarked.
   However, since these acks are not reliably delivered, the sender
   could not distinguish a lost ACK from one that was never sent in
   order to conceal a marked packet.  The nonce sum prevents the
   receiver from concealing individual marked packets by not
   acknowledging them.  Because the nonce and nonce sum are both one bit
   quantities, the sum is no easier to guess than the individual nonces.
   We show the nonce sum calculation below in Figure 1.

各承認は一回だけの合計を運びます。(それは、承認で表されたバイト範囲の上の一回だけの1ビットの合計(排他的論理和、または同等)です)。 あらゆるパケットが個別に承認されるというわけではないので、合計は使用されています、そして、パケットは確かに承認されません。 合計が使用されないなら、個々のパケットが到着したと送付者に立証するために無印のパケットで一回だけを反響できるでしょうに。無印。 しかしながら、これらのacksが確かに届けられないので、送付者は著しいパケットを隠すために決して送られなかったものと無くなっているACKを区別できませんでした。 一回だけの合計は、受信機がそれらを承認しないことによって個々の著しいパケットを隠すのを防ぎます。 一回だけの、そして、一回だけの合計が両方の1ビットの量であるので、合計は個々の一回だけより推測しにくいです。 私たちは以下での図1における一回だけの合計計算を示しています。

    Sender             Receiver
                         initial sum = 1
      -- 1:4 ECT(0)  --> NS = 1 + 0(1:4) = 1(:4)
      <- ACK 4, NS=1 ---
      -- 4:8 ECT(1)  --> NS = 1(:4) + 1(4:8) = 0(:8)
      <- ACK 8, NS=0 ---
      -- 8:12 ECT(1)  -> NS = 0(:8) + 1(8:12) = 1(:12)
      <- ACK 12, NS=1 --
      -- 12:16 ECT(1) -> NS = 1(:12) + 1(12:16) = 0(:16)
      <- ACK 16, NS=0 --

送付者Receiverは合計=1 -- 1: 4ECT(0)に頭文字をつけます-->NSは1+0の1(: 4)(1:4)=<のACK4と等しいです、NS=1--- -- 4:8ECT(1)--1(: 4)+ 1(4:8)=0(: 8)<>ナノ秒=ACK8、ナノ秒=0--- -- 8:12ECT(1)->ナノ秒=0(: 8)の1(: 12)+ 1(8:12)=<のACK12、1 -- -- 12:16ECT(1)->ナノ秒ナノ秒=は1(: 12)+ 1(12:16)=0(: 16)<ACK16と等しいです、ナノ秒=0--

   Figure 1: The calculation of nonce sums at the receiver.

図1: 受信機での一回だけの合計の計算。

   After congestion has occurred and packets have been marked or lost,
   resynchronization of the sender and receiver nonce sums is needed.
   When packets are marked, the nonce is cleared, and the sum of the
   nonces at the receiver will no longer match the sum at the sender.
   Once nonces have been lost, the difference between sender and
   receiver nonce sums is constant until there is further loss.  This
   means that it is possible to resynchronize the sender and receiver
   after congestion by having the sender set its nonce sum to that of
   the receiver.  Because congestion indications do not need to be
   conveyed more frequently than once per round trip, the sender
   suspends checking while the CWR signal is being delivered and resets
   its nonce sum to the receiver's when new data is acknowledged.  This
   has the benefit that the receiver is not explicitly involved in the
   re-synchronization process.  The resynchronization process is shown
   in Figure 2 below.  Note that the nonce sum returned in ACK 12 (NS=0)
   differs from that in the previous example (NS=1), and it continues to
   differ for ACK 16.

混雑が起こって、パケットがマークされるか、または失われた後に、送付者と受信機一回だけ合計の再同期が必要です。 パケットが著しいときに、一回だけはクリアされます、そして、受信機の一回だけの合計はもう送付者で合計に匹敵しないでしょう。 一回だけがいったん失われると、損失がさらにあるまで、送付者と受信機一回だけ合計の違いは一定です。 送付者がいるのによる混雑が受信機のものに一回だけの合計を設定した後にこれは、送付者と受信機を再連動させるのが可能であることを意味します。1周遊旅行あたりの一度より頻繁に混雑指摘が運ばれる必要はないので、送付者は、CWR信号を届けている間、照合を中断させて、新しいデータが承認されるとき、受信機のものに一回だけの合計をリセットします。 これには、受信機が明らかにそうでない利益が再同期の過程にかかわった状態であります。 再同期の過程は以下の図2に示されます。 ACK12(NS=0)で返された一回だけの合計が前の例(NS=1)でそれと異なっていることに注意してください。そうすれば、それはACK16のためにずっと異なります。

Spring, et. al.               Experimental                      [Page 4]

RFC 3540                  Robust ECN Signaling                 June 2003

etスプリング、アル。 電子証券取引ネットワークシグナリング2003年6月に強健な実験的な[4ページ]RFC3540

    Sender              Receiver
                            initial sum = 1
      -- 1:4 ECT(0)       -> NS = 1 + 0(1:4) = 1(:4)
      <- ACK 4, NS=1      --
      -- 4:8 ECT(1) -> CE -> NS = 1(:4) + ?(4:8) = 1(:8)
      <- ACK 8, ECE NS=1  --
      -- 8:12 ECT(1), CWR -> NS = 1(:8) + 1(8:12) = 0(:12)
      <- ACK 12, NS=0     --
      -- 12:16 ECT(1)     -> NS = 0(:12) + 1(12:16) = 1(:16)
      <- ACK 16, NS=1     --

送付者..初期..合計..等しい..等しい..等しい..等しい

   Figure 2: The calculation of nonce sums at the receiver when a
      packet (4:8) is marked.  The receiver may calculate the wrong
      nonce sum when the original nonce information is lost after a
      packet is marked.

図2: パケット(4:8)であるときに、受信機での一回だけの合計の計算は著しいです。 パケットが著しくなった後にオリジナルの一回だけの情報が無くなるとき、受信機は間違った一回だけの合計について計算するかもしれません。

   Third, we need to reconcile that nonces are sent with packets but
   acknowledgements cover byte ranges.  Acknowledged byte boundaries
   need not match the transmitted boundaries, and information can be
   retransmitted in packets with different byte boundaries.  We discuss
   the first issue, how a receiver sets a nonce when acknowledging part
   of a segment, in Section 6.1. The second question, what nonce to send
   when retransmitting smaller segments as a large segment, has a simple
   answer: ECN is disabled for retransmissions, so can carry no nonce.
   Because retransmissions are associated with congestion events, nonce
   checking is suspended until after CWR is acknowledged and the
   congestion event is over.

3番目に、私たちは、それを和解させる必要があります。パケットと共に一回だけを送りますが、承認はバイト範囲をカバーしています。 承認されたバイト境界は伝えられた境界に合う必要はありません、そして、パケットで異なったバイト境界で情報は再送できます。 私たちはセクション6.1でセグメントの一部を承認するとき、受信機が創刊号、どう一回だけを設定するかについて議論します。 2番目の質問(大きいセグメントとして、より小さいセグメントを再送するとき発信するどんな一回だけ)に、簡単な答えがあるか: 電子証券取引ネットワークは、「再-トランスミッション」のために無能にされるので、一回だけを全く運ぶことができません。 「再-トランスミッション」が混雑出来事に関連しているので、CWRが承認された後まで一回だけの照合は中断します、そして、混雑イベントは終わっています。

   The next sections describe the detailed behavior of senders, routers
   and receivers, starting with sender transmit behavior, then around
   the ECN signaling loop, and finish with sender acknowledgement
   processing.

次のセクションは、送付者、ルータ、および受信機の詳細な動きについて説明して、送付者をきっかけにそして、電子証券取引ネットワークシグナリング輪の周りに振舞いを伝えて、送付者承認処理で終わります。

3.  Sender Behavior (Transmit)

3. 送付者の振舞い(伝えます)

   Senders manage CWR and ECN-Echo as before.  In addition, they must
   place nonces on packets as they are transmitted and check the
   validity of the nonce sums in acknowledgments as they are received.
   This section describes the transmit process.

送付者は従来と同様CWRと電子証券取引ネットワーク-エコーを管理します。 それらが受け取られているので、さらに、彼らは、それらが伝えられるのに応じて一回だけをパケットに置いて、承認で一回だけの合計の正当性をチェックしなければなりません。 このセクションは伝えることの過程について説明します。

   To place a one bit nonce value on every ECN-capable IP packet, the
   sender uses the two ECT codepoints: ECT(0) represents a nonce of 0,
   and ECT(1) a nonce of 1.  As in ECN, retransmissions are not ECN-
   capable, so carry no nonce.

あらゆる電子証券取引ネットワークできるIPパケットに1ビットの一回だけの値を置くために、送付者は2ECT codepointsを使用します: ECT(0)は0の一回だけを表します、そして、ECT(1)は1の一回だけを表します。 電子証券取引ネットワークのように、「再-トランスミッション」ができる電子証券取引ネットワークでないので、一回だけを全く運ばないでください。

   The sender maintains a mapping from each packet's end sequence number
   to the expected nonce sum (not the nonce placed in the original
   transmission) in the acknowledgement bearing that sequence number.

送付者は、その一連番号の承認ベアリングで各パケットの終わりの一連番号から予想された一回だけの合計までのマッピングが(オリジナルのトランスミッションに置かれなかったいずれの一回だけも)であると主張します。

Spring, et. al.               Experimental                      [Page 5]

RFC 3540                  Robust ECN Signaling                 June 2003

etスプリング、アル。 電子証券取引ネットワークシグナリング2003年6月に強健な実験的な[5ページ]RFC3540

4.  Router Behavior

4. ルータの振舞い

   Routers behave as specified in [RFC3168].  By marking packets to
   signal congestion, the original value of the nonce, in ECT(0) or
   ECT(1), is removed.  Neither the receiver nor any other party can
   unmark the packet without successfully guessing the value of the
   original nonce.

ルータは[RFC3168]で指定されるように振る舞います。 混雑に合図するためにパケットをマークすることによって、ECT(0)かECT(1)の一回だけの元の値を取り除きます。 首尾よくオリジナルの一回だけの値を推測しないで、受信機もいかなる他のパーティーもパケットを非マークできません。

5.  Receiver Behavior (Receive and Transmit)

5. 受信機の振舞い(受けて、伝えます)

   ECN-nonce receivers maintain the nonce sum as in-order packets arrive
   and return the current nonce sum in each acknowledgement.  Receiver
   behavior is otherwise unchanged from [RFC3168].  Returning the nonce
   sum is optional, but recommended, as senders are allowed to
   discontinue sending ECN-capable packets to receivers that do not
   support the ECN-nonce.

電子証券取引ネットワーク-一回だけ受信機は、オーダーにおけるパケットが到着するとき一回だけの合計を維持して、各承認で現在の一回だけの合計を返します。 そうでなければ、受信機の振舞いは[RFC3168]から変わりがありません。 一回だけの合計を返すのは、任意ですが、お勧めです、送付者が、電子証券取引ネットワーク-一回だけを支持しない受信機に電子証券取引ネットワークできるパケットを送るのを中止できるとき。

   As packets are removed from the queue of out-of-order packets to be
   acknowledged, the nonce is recovered from the IP header.  The nonce
   is added to the current nonce sum as the acknowledgement sequence
   number is advanced for the recent packet.

承認されるために故障しているパケットの待ち行列からパケットを取り除くとき、IPヘッダーから一回だけを取り戻します。 承認一連番号が最近のパケットのために進められるとき、一回だけは現在の一回だけの合計に加えられます。

   In the case of marked packets, one or more nonce values may be
   unknown to the receiver.  In this case the missing nonce values are
   ignored when calculating the sum (or equivalently a value of zero is
   assumed) and ECN-Echo will be set to signal congestion to the sender.

著しいパケットのケースでは、受信機において、1つ以上の一回だけの値が未知であるかもしれません。この場合合計(同等に、ゼロの値は想定される)と電子証券取引ネットワーク-エコーが送付者に混雑に合図するように設定されると見込むとき、なくなった一回だけの値は無視されます。

   Returning the nonce sum corresponding to a given acknowledgement is
   straightforward.  It is carried in a single "NS" (Nonce Sum) bit in
   the TCP header.  This bit is adjacent to the CWR and ECN-Echo bits,
   set as Bit 7 in byte 13 of the TCP header, as shown below:

与えられた承認に対応する一回だけの合計を返すのは簡単です。 それはTCPヘッダーで単一の「ナノ秒」(一回だけの合計)ビットで運ばれます。 このビットは以下に示されるようにBit7としてTCPヘッダーのバイト13で用意ができているCWRと電子証券取引ネットワーク-エコービットに隣接しています:

     0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |               |           | N | C | E | U | A | P | R | S | F |
   | Header Length | Reserved  | S | W | C | R | C | S | S | Y | I |
   |               |           |   | R | E | G | K | H | T | N | N |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | N| C| E| U| A| P| R| S| F| | ヘッダ長| 予約されます。| S| W| C| R| C| S| S| Y| I| | | | | R| E| G| K| H| T| N| N| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   Figure 3: The new definition of bytes 13 and 14 of the TCP Header.

図3: TCP Headerのバイト13と14の新しい定義。

   The initial nonce sum is 1, and is included in the SYN/ACK and ACK of
   the three way TCP handshake.  This allows the other endpoint to infer
   nonce support, but is not a negotiation, in that the receiver of the
   SYN/ACK need not check if NS is set to decide whether to set NS in
   the subsequent ACK.

初期の一回だけ合計は、1であり、3方法のSYN/ACKとACKに含まれています。TCP握手。 これは、もう片方の終点が一回だけのサポートを推論するのを許容しますが、交渉ではありません、SYN/ACKの受信機が、NSがその後のACKにNSをはめ込むかどうか決めるように用意ができているかどうかチェックする必要はないので。

Spring, et. al.               Experimental                      [Page 6]

RFC 3540                  Robust ECN Signaling                 June 2003

etスプリング、アル。 電子証券取引ネットワークシグナリング2003年6月に強健な実験的な[6ページ]RFC3540

6.  Sender Behavior (Receive)

6. 送付者の振舞い(受信します)

   This section completes the description of sender behavior by
   describing how senders check the validity of the nonce sums.

このセクションは、送付者がどう一回だけの合計の正当性をチェックするかを説明することによって、送付者の振舞いの記述を終了します。

   The nonce sum is checked when an acknowledgement of new data is
   received, except during congestion recovery when additional ECN-Echo
   signals would be ignored.  Checking consists of comparing the correct
   nonce sum stored in a buffer to that carried in the acknowledgement,
   with a correction described in the following subsection.

追加電子証券取引ネットワーク-エコー信号が無視されるだろうというときの混雑回復を除いて、新しいデータの承認を受けるとき、一回だけの合計をチェックします。 照合はバッファに承認で運ばれたそれに格納された正しい一回だけの合計を比較するのから成ります、修正が以下の小区分で説明されている状態で。

   If ECN-Echo is not set, the receiver claims to have received no
   marked packets, and can therefore compute and return the correct
   nonce sum.  To conceal a mark, the receiver must successfully guess
   the sum of the nonces that it did not receive, because at least one
   packet was marked and the corresponding nonce was erased.  Provided
   the individual nonces are equally likely to be 0 or 1, their sum is
   equally likely to be 0 or 1.  In other words, any guess is equally
   likely to be wrong and has a 50-50 chance of being caught by the
   sender.  Because each new acknowledgement is an independent trial, a
   cheating receiver is likely to be caught after a small number of
   lies.

電子証券取引ネットワーク-エコーが設定されないなら、したがって、持っている受信機クレームは、正しい一回だけの合計をどんな著しいパケットも受けないで、計算して、返すことができます。 マークを隠すために、受信機は首尾よくそれが受けなかった一回だけの合計を推測しなければなりません、少なくとも1つのパケットがマークされて、対応する一回だけが消されたので。 個々の一回だけが等しく0か1である傾向があるなら、それらの合計は等しく0か1である傾向があります。 言い換えれば、どんな推測も、間違っているのが等しくありそうであり、送付者によって捕らえられるという50-50機会を持っています。 それぞれの新しい承認が独立しているトライアルであるので、不正行為する受信機は少ない数の偽りの後に捕らえられそうです。

   If ECN-Echo is set, the receiver is sending a congestion signal and
   it is not necessary to check the nonce sum.  The congestion window
   will be halved, CWR will be set on the next packet with new data
   sent, and ECN-Echo will be cleared once the CWR signal is received,
   as in [RFC3168].  During this recovery process, the sum may be
   incorrect because one or more nonces were not received.  This does
   not matter during recovery, because TCP invokes congestion mechanisms
   at most once per RTT, whether there are one or more losses during
   that period.

電子証券取引ネットワーク-エコーが設定されるなら、受信機は混雑信号を送ります、そして、一回だけの合計をチェックするのは必要ではありません。 混雑ウィンドウは半分にされるでしょう、そして、CWRは次のパケットの上で新しいデータを送って用意ができるでしょう、そして、CWR信号がいったん受信されるようになると、電子証券取引ネットワーク-エコーはクリアされるでしょう、[RFC3168]のように。 この回復の過程の間、1つ以上の一回だけが受け取られなかったので、合計は不正確であるかもしれません。 これは回復の間、重要ではありません、TCPが高々1RTTに一度混雑メカニズムを呼び出すので、1回以上の損失がその期間、あるか否かに関係なく。

6.1.  Resynchronization After Loss or Mark

6.1. 損失かマークの後のResynchronization

   After recovery, it is necessary to re-synchronize the sender and
   receiver nonce sums so that further acknowledgments can be checked.
   When the receiver's sum is incorrect, it will remain incorrect until
   further loss.

回復の後に、送付者と受信機一回だけ合計を再同期させるのが、さらなる承認をチェックできるくらい必要です。 受信機の合計が不正確であるときに、それは一層の損失まで不正確なままで残るでしょう。

   This leads to a simple re-synchronization mechanism where the sender
   resets its nonce sum to that of the receiver when it receives an
   acknowledgment for new data sent after the congestion window was
   reduced.  When responding to explicit congestion signals, this will
   be the first acknowledgement without the ECN-Echo flag set: the
   acknowledgement of the packet containing the CWR flag.

これは混雑ウィンドウが減少した後に送られた新しいデータのための承認を受けるとき送付者が受信機のものに一回だけの合計をリセットする簡単な再同期メカニズムに通じます。 明白な混雑信号に応じるとき、これは電子証券取引ネットワーク-エコー旗のセットがなければ最初の承認でしょう: CWR旗を含むパケットの承認。

Spring, et. al.               Experimental                      [Page 7]

RFC 3540                  Robust ECN Signaling                 June 2003

etスプリング、アル。 電子証券取引ネットワークシグナリング2003年6月に強健な実験的な[7ページ]RFC3540

    Sender              Receiver
                             initial sum = 1
      -- 1:4 ECT(0)       -> NS = 1 + 0(1:4) = 1(:4)
      <- ACK 4, NS=1      --
      -- 4:8 ECT(1) -> LOST
      -- 8:12 ECT(1)      -> nonce sum calculation deferred
                               until in-order data received
      <- ACK 4, NS=0      --
      -- 12:16 ECT(1)     -> nonce sum calculation deferred
      <- ACK 4, NS=0      --
      -- 4:8 retransmit   -> NS = 1(:4) + ?(4:8) +
                                  1(8:12) + 1(12:16) = 1(:16)
      <- ACK 16, NS=1     --
      -- 16:20 ECT(1) CWR ->
      <- ACK 20, NS=0     -- NS = 1(:16) + 1(16:20) = 0(:20)

Sender Receiver initial sum = 1 -- 1:4 ECT(0) -> NS = 1 + 0(1:4) = 1(:4) <- ACK 4, NS=1 -- -- 4:8 ECT(1) -> LOST -- 8:12 ECT(1) -> nonce sum calculation deferred until in-order data received <- ACK 4, NS=0 -- -- 12:16 ECT(1) -> nonce sum calculation deferred <- ACK 4, NS=0 -- -- 4:8 retransmit -> NS = 1(:4) + ?(4:8) + 1(8:12) + 1(12:16) = 1(:16) <- ACK 16, NS=1 -- -- 16:20 ECT(1) CWR -> <- ACK 20, NS=0 -- NS = 1(:16) + 1(16:20) = 0(:20)

   Figure 4: The calculation of nonce sums at the receiver when a
      packet is lost, and resynchronization after loss.  The nonce sum
      is not changed until the cumulative acknowledgement is advanced.

図4: パケットが無くなるときの受信機での一回だけの合計の計算、および損失の後の再同期。 累積している承認が高度になるまで、一回だけの合計は変えられません。

   In practice, resynchronization can be accomplished by storing a bit
   that has the value one if the expected nonce sum stored by the sender
   and the received nonce sum in the acknowledgement of CWR differ, and
   zero otherwise.  This synchronization offset bit can then be used in
   the comparison between expected nonce sum and received nonce sum.

実際には、別の方法で再同期を少し格納して、送付者によって格納された予想された一回だけの合計とCWRの承認における容認された一回だけの合計が異なるなら値1を持っているゼロで達成できます。 そして、予想された一回だけの合計と容認された一回だけの合計での比較にこの同期オフセットビットを使用できます。

   The sender should ignore the nonce sum returned on any
   acknowledgements bearing the ECN-echo flag.

送付者は電子証券取引ネットワーク-エコー旗を持っているどんな承認のときにも返された一回だけの合計を無視するべきです。

   When an acknowledgment covers only a portion of a segment, such as
   when a middlebox resegments at the TCP layer instead of fragmenting
   IP packets, the sender should accept the nonce sum expected at the
   next segment boundary.  In other words, an acknowledgement covering
   part of an original segment will include the nonce sum expected when
   the entire segment is acknowledged.

承認がセグメントの部分だけをカバーするとき、IPパケットを断片化することの代わりにTCP層のmiddlebox resegmentsであるときに、送付者が次のセグメント境界で期待された一回だけの合計を受け入れるべきであるように、ものです。 言い換えれば、オリジナルのセグメントの一部を覆う承認は全体のセグメントが承認されるとき期待された一回だけの合計を含むでしょう。

   Finally, in ECN, senders can choose not to indicate ECN capability on
   some packets for any reason.  An ECN-nonce sender must resynchronize
   after sending such ECN-incapable packets, as though a CWR had been
   sent with the first new data after the ECN-incapable packets.  The
   sender loses protection for any unacknowledged packets until
   resynchronization occurs.

最終的に、電子証券取引ネットワークでは、送付者は、どんな理由でもいくつかのパケットの上に電子証券取引ネットワーク能力を示さないのを選ぶことができます。 そのような電子証券取引ネットワーク不可能なパケットを送った後に電子証券取引ネットワーク-一回だけ送付者は再連動しなければなりません、まるで電子証券取引ネットワーク不可能なパケットの後の最初の新しいデータと共にCWRを送ったかのように。 再同期が現れるまで、送付者はどんな不承認のパケットのための保護も失います。

Spring, et. al.               Experimental                      [Page 8]

RFC 3540                  Robust ECN Signaling                 June 2003

etスプリング、アル。 電子証券取引ネットワークシグナリング2003年6月に強健な実験的な[8ページ]RFC3540

6.2.  Sender Behavior - Incorrect Nonce Received

6.2. 送付者の振舞い--不正確な一回だけは受信されました。

   The sender's response to an incorrect nonce is a matter of policy.
   It is separate from the checking mechanism and does not need to be
   handled uniformly by senders.  Further, checking received nonce sums
   at all is optional, and may be disabled.

不正確な一回だけへの送付者の応答は方針の問題です。 それによって照合メカニズムから別々であり、送付者によって一様に扱われる必要はありません。 さらに、全く容認された一回だけの合計をチェックするのは、任意であり、障害があるかもしれません。

   If the receiver has never sent a non-zero nonce sum, the sender can
   infer that the receiver does not understand the nonce, and rate limit
   the connection, place it in a lower-priority queue, or cease setting
   ECT in outgoing segments.

受信機が非ゼロの一回だけの合計を一度も送ったことがなくて、送付者が、受信機が一回だけを理解していないと推論できて、レートが接続を制限するなら、低優先度待ち行列にそれを置くか、または外向的なセグメントにECTをはめ込むのをやめてください。

   If the received nonce sum has been set in a previous acknowledgement,
   the sender might infer that a network device has interfered with
   correct ECN signaling between ECN-nonce supporting endpoints.  The
   minimum response to an incorrect nonce is the same as the response to
   a received ECE.  However, to compensate for hidden congestion
   signals, the sender might reduce the congestion window to one segment
   and cease setting ECT in outgoing segments.  An incorrect nonce sum
   is a sign of misbehavior or error between ECN-nonce supporting
   endpoints.

容認された一回だけの合計が前の承認で設定されたなら、送付者は、ネットワーク装置が電子証券取引ネットワーク-一回だけサポート終点の間で合図する正しい電子証券取引ネットワークを妨げたと推論するかもしれません。 不正確な一回だけへの最小の応答は容認されたECEへの応答と同じです。 しかしながら、送付者は、隠された混雑信号を補うために、混雑ウィンドウを1つのセグメントまで減少させて、外向的なセグメントにECTをはめ込むのをやめるかもしれません。 不正確な一回だけの合計は電子証券取引ネットワーク-一回だけサポート終点の間の不正行為か誤りのサインです。

6.2.1.  Using the ECN-nonce to Protect Against Other Misbehaviors

6.2.1. 他の不正行為から守るのに電子証券取引ネットワーク-一回だけを使用します。

   The ECN-nonce can provide robustness beyond checking that marked
   packets are signaled to the sender.  It also ensures that dropped
   packets cannot be concealed from the sender (because their nonces
   have been lost).  Drops could potentially be concealed by a faulty
   TCP implementation, certain attacks, or even a hypothetical TCP
   accelerator.  Such an accelerator could gamble that it can either
   successfully "fast start" to a preset bandwidth quickly, retry with
   another connection, or provide reliability at the application level.
   If robustness against these faults is also desired, then the ECN-
   nonce should not be disabled.  Instead, reducing the congestion
   window to one, or using a low-priority queue, would penalize faulty
   operation while providing continued checking.

著しいパケットが送付者に合図されるのをチェックすることを超えて電子証券取引ネットワーク-一回だけは丈夫さを提供できます。 また、それは、送付者から低下しているパケットを隠すことができないのを確実にします(それらの一回だけが失われたので)。 不完全なTCP実現、ある攻撃、または仮定しているTCPアクセラレータはさえ潜在的に低下を隠すことができました。 aは帯域幅をあらかじめセットしました。そのようなアクセルが、それが首尾よく「速く、始まることができること」を賭けるかもしれない、すぐに、別の接続と共に再試行するか、またはアプリケーションレベルにおける信頼性を提供してください。 また、これらの欠点に対する丈夫さを望んでいるなら、電子証券取引ネットワーク一回だけを無能にするべきではありません。 代わりに、混雑ウィンドウを1まで減少させるか、または低い優先待ち行列を使用すると、不完全な操作は継続的な照合を提供している間、罰せられるでしょう。

   The ECN-nonce can also detect misbehavior in Eifel [Eifel], a
   recently proposed mechanism for removing the retransmission ambiguity
   to improve TCP performance.  A misbehaving receiver might claim to
   have received only original transmissions to convince the sender to
   undo congestion actions.  Since retransmissions are sent without ECT,
   and thus no nonce, returning the correct nonce sum confirms that only
   original transmissions were received.

また、電子証券取引ネットワーク-一回だけは、TCP性能を向上させるために「再-トランスミッション」のあいまいさを取り除くためにアイフェル高原[アイフェル高原]、最近提案されたメカニズムにおける不正行為を検出できます。 ふらちな事する受信機は、混雑動作を元に戻すように送付者を説得するためにオリジナルのトランスミッションだけを受けたと主張するかもしれません。 ECTにもかかわらず、その結果、どんな一回だけなしでも「再-トランスミッション」を送らないので、正しい一回だけの合計を返すのは、オリジナルのトランスミッションだけが受けられたと確認します。

Spring, et. al.               Experimental                      [Page 9]

RFC 3540                  Robust ECN Signaling                 June 2003

etスプリング、アル。 電子証券取引ネットワークシグナリング2003年6月に強健な実験的な[9ページ]RFC3540

7.  Interactions

7. 相互作用

7.1.  Path MTU Discovery

7.1. 経路MTU発見

   As described in RFC3168, use of the Don't Fragment bit with ECN is
   recommended.  Receivers that receive unmarked fragments can
   reconstruct the original nonce to conceal a marked fragment.  The
   ECN-nonce cannot protect against misbehaving receivers that conceal
   marked fragments, so some protection is lost in situations where Path
   MTU discovery is disabled.

RFC3168で説明されるように、電子証券取引ネットワークと共に噛み付かれたFragmentではなく、ドンの使用はお勧めです。 無印の断片を受ける受信機は、著しい断片を隠すためにオリジナルの一回だけを再建できます。 電子証券取引ネットワーク-一回だけが著しい断片を隠すふらちな事する受信機から守ることができないので、何らかの保護がPath MTU発見は障害がある状況で失われています。

   When responding to a small path MTU, the sender will retransmit a
   smaller frame in place of a larger one.  Since these smaller packets
   are retransmissions, they will be ECN-incapable and bear no nonce.
   The sender should resynchronize on the first newly transmitted
   packet.

MTU、小さい経路に応じるとき、送付者は、より大きいものに代わって、より小さいフレームを再送するでしょう。 これらのより小さいパケットが「再-トランスミッション」であるので、彼らは、電子証券取引ネットワーク不可能であり、一回だけに全く堪えないでしょう。 送付者は最初の新たに伝えられたパケットの上で再連動するべきです。

7.2.  SACK

7.2. 袋

   Selective acknowledgements allow receivers to acknowledge out of
   order segments as an optimization.  It is not necessary to modify the
   selective acknowledgment option to fit per-range nonce sums, because
   SACKs cannot be used by a receiver to hide a congestion signal.  The
   nonce sum corresponds only to the data acknowledged by the cumulative
   acknowledgement.

選択している承認は、最適化として不適切なセグメントを承認するために受信機を許容します。 1範囲あたりの一回だけの合計に合うように選択している承認オプションを変更するのは必要ではありません、SACKsが受信機によって使用されて、混雑信号を隠すことがないことができるので。 一回だけの合計は累積している承認で承認されたデータだけに対応しています。

7.3.  IPv6

7.3. IPv6

   Although the IPv4 header is protected by a checksum, this is not the
   case with IPv6, making undetected bit errors in the IPv6 header more
   likely.  Bit errors that compromise the integrity of the congestion
   notification fields may cause an incorrect nonce to be received, and
   an incorrect nonce sum to be returned.

IPv4ヘッダーはチェックサムによって保護されますが、これはIPv6があるそうではありません、おそらく、IPv6ヘッダーで非検出された噛み付いている誤りをして。 混雑通知分野の保全で妥協する噛み付いている誤りで、不正確な一回だけが受け取られるのを返して、不正確な一回だけの合計を返すかもしれません。

8.  Security Considerations

8. セキュリティ問題

   The random one-bit nonces need not be from a cryptographic-quality
   pseudo-random number generator.  A strong random number generator
   would compromise performance.  Consequently, the sequence of random
   nonces should not be used for any other purpose.

無作為の1ビットの一回だけは暗号の品質疑似乱数生成器から来ている必要はありません。 強い乱数発生器は性能で妥協するでしょう。 その結果、いかなる他の目的にも無作為の一回だけの系列を使用するべきではありません。

   Conversely, the pseudo-random bit sequence should not be generated by
   a linear feedback shift register [Schneier], or similar scheme that
   would allow an adversary who has seen several previous bits to infer
   the generation function and thus its future output.

逆に、擬似ランダムの噛み付いている系列は、機能が直線的なフィードバック・シフト・レジスタ[シュナイアー]、または前の数ビットを見た敵が世代を推論できる同様の計画で発生して、その結果、今後の出力は発生するべきではありません。

Spring, et. al.               Experimental                     [Page 10]

RFC 3540                  Robust ECN Signaling                 June 2003

etスプリング、アル。 電子証券取引ネットワークシグナリング2003年6月に強健な実験的な[10ページ]RFC3540

   Although the ECN-nonce protects against concealment of congestion
   signals and optimistic acknowledgement, it provides no additional
   protection for the integrity of the connection.

電子証券取引ネットワーク-一回だけは混雑信号と楽観的な承認の隠すことから守りますが、それは接続の保全のためのどんな追加保護も提供しません。

9.  IANA Considerations

9. IANA問題

   The Nonce Sum (NS) is carried in a reserved TCP header bit that must
   be allocated.  This document describes the use of Bit 7, adjacent to
   the other header bits used by ECN.

Nonce Sum(NS)は割り当てなければならない予約されたTCPヘッダービットで運ばれます。 このドキュメントは電子証券取引ネットワークによって使用された他のヘッダービットに隣接してBit7の使用について説明します。

   The codepoint for the NS flag in the TCP header is specified by the
   Standards Action of this RFC, as is required by RFC 2780.  The IANA
   has added the following to the registry for "TCP Header Flags":

TCPヘッダーのNS旗のためのcodepointはこのRFCのStandards Actionによって指定されます、RFC2780が必要であるように。 IANAは「TCPヘッダー旗」のために登録に以下を加えました:

   RFC 3540 defines bit 7 from the Reserved field to be used for the
   Nonce Sum, as follows:

RFC3540はNonce Sumに以下の通り使用されるためにReserved分野からビット7を定義します:

     0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |               |           | N | C | E | U | A | P | R | S | F |
   | Header Length | Reserved  | S | W | C | R | C | S | S | Y | I |
   |               |           |   | R | E | G | K | H | T | N | N |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | N| C| E| U| A| P| R| S| F| | ヘッダ長| 予約されます。| S| W| C| R| C| S| S| Y| I| | | | | R| E| G| K| H| T| N| N| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   TCP Header Flags

TCPヘッダー旗

   Bit      Name                                    Reference
   ---      ----                                    ---------
    7        NS (Nonce Sum)                         [RFC 3540]

噛み付いている名前参照--- ---- --------- 7ナノ秒(一回だけの合計)[RFC3540]

10.  Conclusion

10. 結論

   The ECN-nonce is a simple modification to the ECN signaling mechanism
   that improves ECN's robustness by preventing receivers from
   concealing marked (or dropped) packets.  The intent of this work is
   to help improve the robustness of congestion control in the Internet.
   The modification retains the character and simplicity of existing ECN
   signaling.  It is also practical for deployment in the Internet.  It
   uses the ECT(0) and ECT(1) codepoints and one TCP header flag (as
   well as CWR and ECN-Echo) and has simple processing rules.

電子証券取引ネットワーク-一回だけは受信機が著しい(または、落とされる)パケットを隠すのを防ぐことによって電子証券取引ネットワークの丈夫さを改良する電子証券取引ネットワークシグナル伝達機構への簡単な変更です。 この仕事の意図はインターネットにおける、輻輳制御の丈夫さを改良するのを助けることです。 変更は既存の電子証券取引ネットワークシグナリングのキャラクタと簡単さを保有します。 また、インターネットでの展開に、それも実用的です。 それは、ECT(0)、ECT(1) codepoints、および1個のTCPヘッダー旗(CWRと電子証券取引ネットワーク-エコーと同様に)を使用して、簡単な処理規則を持っています。

Spring, et. al.               Experimental                     [Page 11]

RFC 3540                  Robust ECN Signaling                 June 2003

etスプリング、アル。 電子証券取引ネットワークシグナリング2003年6月に強健な実験的な[11ページ]RFC3540

11.  References

11. 参照

   [ECN]      "The ECN Web Page", URL
              "http://www.icir.org/floyd/ecn.html".

[電子証券取引ネットワーク] 「電子証券取引ネットワークウェブページ」、URL" http://www.icir.org/floyd/ecn.html "。

   [RFC3168]  Ramakrishnan, K., Floyd, S. and D. Black, "The addition of
              explicit congestion notification (ECN) to IP", RFC 3168,
              September 2001.

[RFC3168] RamakrishnanとK.とフロイドとS.とD.Black、「明白な混雑通知(電子証券取引ネットワーク)のIPへの追加」、RFC3168、2001年9月。

   [Eifel]    R. Ludwig and R. Katz. The Eifel Algorithm: Making TCP
              Robust Against Spurious Retransmissions. Computer
              Communications Review, January, 2000.

[アイフェル高原]のR.ラドウィグとR.キャッツ。 アイフェル高原アルゴリズム: TCPを偽物のRetransmissionsに対して強健にします。 コンピュータコミュニケーションは2000年1月に再検討されます。

   [B97]      Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[B97] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [Savage]   S. Savage, N. Cardwell, D. Wetherall, T. Anderson.  TCP
              congestion control with a misbehaving receiver. SIGCOMM
              CCR, October 1999.

[サヴェージ]S.サヴェージ、N.カードウェル、D.Wetherall、T.アンダーソン。 1999年10月のふらちな事する受信機SIGCOMM CCRとのTCP輻輳制御。

   [Schneier] Bruce Schneier. Applied Cryptography, 2nd ed., 1996

[シュナイアー]ブルース・シュナイアー。 適用されたCryptography、2番目の教育、1996

12.  Acknowledgements

12. 承認

   This note grew out of research done by Stefan Savage, David Ely,
   David Wetherall, Tom Anderson and Neil Spring.  We are very grateful
   for feedback and assistance from Sally Floyd.

この音はステファン・サヴェージ、デヴィッド・イーリー、デヴィッドWetherall、トム・アンダーソン、およびニールSpringによって行われた研究から成長しました。 私たちはサリー・フロイドからのフィードバックと支援に非常に感謝しています。

13.  Authors' Addresses

13. 作者のアドレス

   Neil Spring
   EMail: nspring@cs.washington.edu

ニール春のメール: nspring@cs.washington.edu

   David Wetherall
   Department of Computer Science and Engineering, Box 352350
   University of Washington
   Seattle WA 98195-2350
   EMail: djw@cs.washington.edu

コンピュータサイエンスと工学のデヴィッドWetherall部、箱352350のワシントン大学シアトルワシントン98195-2350メール: djw@cs.washington.edu

   David Ely
   Computer Science and Engineering, 352350
   University of Washington
   Seattle, WA 98195-2350
   EMail: ely@cs.washington.edu

デヴィッド・イーリー・コンピュータサイエンスと工学、352350ワシントン大学シアトル、ワシントン98195-2350はメールします: ely@cs.washington.edu

Spring, et. al.               Experimental                     [Page 12]

RFC 3540                  Robust ECN Signaling                 June 2003

etスプリング、アル。 電子証券取引ネットワークシグナリング2003年6月に強健な実験的な[12ページ]RFC3540

14.  Full Copyright Statement

14. 完全な著作権宣言文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Spring, et. al.               Experimental                     [Page 13]

etスプリング、アル。 実験的[13ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

フォーム要素の属性名の『ドット( . )』は『アンダーバー( _ )』に変わります

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る