RFC2883 日本語訳
2883 An Extension to the Selective Acknowledgement (SACK) Option forTCP. S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky. July 2000. (Format: TXT=35794 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Floyd
Request for Comments: 2883 ACIRI
Category: Standards Track J. Mahdavi
Novell
M. Mathis
Pittsburgh Supercomputing Center
M. Podolsky
UC Berkeley
July 2000
コメントを求めるワーキンググループS.フロイド要求をネットワークでつないでください: 2883年のACIRIカテゴリ: 標準化過程J.MahdaviノベルM.マシスピッツバーグスーパーコンピューティングセンターM.ポドルスキーUCバークレー2000年7月
An Extension to the Selective Acknowledgement (SACK) Option for TCP
TCPのための選択している承認(袋)オプションへの拡大
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This note defines an extension of the Selective Acknowledgement (SACK) Option [RFC2018] for TCP. RFC 2018 specified the use of the SACK option for acknowledging out-of-sequence data not covered by TCP's cumulative acknowledgement field. This note extends RFC 2018 by specifying the use of the SACK option for acknowledging duplicate packets. This note suggests that when duplicate packets are received, the first block of the SACK option field can be used to report the sequence numbers of the packet that triggered the acknowledgement. This extension to the SACK option allows the TCP sender to infer the order of packets received at the receiver, allowing the sender to infer when it has unnecessarily retransmitted a packet. A TCP sender could then use this information for more robust operation in an environment of reordered packets [BPS99], ACK loss, packet replication, and/or early retransmit timeouts.
この注意はTCPのためにSelective Acknowledgement(SACK)オプション[RFC2018]の拡大を定義します。 RFC2018はSACKオプションの順序が狂ってTCPの累積している承認分野でカバーされなかったデータを承認する使用を指定しました。 この注意は、SACKオプションの写しパケットを承認する使用を指定することによって、RFC2018を広げています。 この注意は、写しパケットが受け取られているとき、承認の引き金となったパケットの一連番号を報告するのにSACKオプション・フィールドの最初のブロックを使用できるのを示します。 不必要にパケットを再送したとき、SACKオプションへのこの拡大で、TCP送付者は推論する送付者を許容する受信機で受け取られていているパケットの注文を推論できます。 次に、TCP送付者は、より体力を要している操作に再命令されたパケット[BPS99]の環境でこの情報を使用できました、ACKの損失、パケット模写、タイムアウトは早く再送されます。
1. Conventions and Acronyms
1. コンベンションと頭文字語
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 [B97].
キーワードが解釈しなければならない、本書では現れるとき、[B97]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
Floyd, et al. Standards Track [Page 1] RFC 2883 SACK Extension July 2000
フロイド、他 RFC2883が拡大2000年7月に略奪する標準化過程[1ページ]
2. Introduction
2. 序論
The Selective Acknowledgement (SACK) option defined in RFC 2018 is used by the TCP data receiver to acknowledge non-contiguous blocks of data not covered by the Cumulative Acknowledgement field. However, RFC 2018 does not specify the use of the SACK option when duplicate segments are received. This note specifies the use of the SACK option when acknowledging the receipt of a duplicate packet [F99]. We use the term D-SACK (for duplicate-SACK) to refer to a SACK block that reports a duplicate segment.
RFC2018で定義されたSelective Acknowledgement(SACK)オプションはTCPデータ受信装置によって使用されて、Cumulative Acknowledgement分野でカバーされなかった非隣接のブロックのデータを承認します。 しかしながら、写しセグメントが受け取られているとき、RFC2018はSACKオプションの使用を指定しません。 写しパケット[F99]の領収書を受け取ったことを知らせるとき、この注意はSACKオプションの使用を指定します。 私たちは、写しセグメントを報告するSACKブロックを示すのにD-SACKという用語を使用します(写し-SACKのために)。
This document does not make any changes to TCP's use of the cumulative acknowledgement field, or to the TCP receiver's decision of *when* to send an acknowledgement packet. This document only concerns the contents of the SACK option when an acknowledgement is sent.
このドキュメントは、確認応答パケットを送るために累積している承認分野のTCPの使用、または、*であることのTCP受信機の*の決定へのどんな変更も行いません。 承認を送るときだけ、このドキュメントはSACKオプションのコンテンツに関係があります。
This extension is compatible with current implementations of the SACK option in TCP. That is, if one of the TCP end-nodes does not implement this D-SACK extension and the other TCP end-node does, we believe that this use of the D-SACK extension by one of the end nodes will not introduce problems.
この拡大はTCPでのSACKオプションの現在の実現と互換性があります。 すなわち、TCPエンドノードの1つがTCPエンドノードがするこのD-SACK拡張子ともう片方を実行しないなら、私たちは、エンドノードの1つによるD-SACK拡張子のこの使用が問題を紹介しないと信じています。
The use of D-SACK does not require separate negotiation between a TCP sender and receiver that have already negotiated SACK capability. The absence of separate negotiation for D-SACK means that the TCP receiver could send D-SACK blocks when the TCP sender does not understand this extension to SACK. In this case, the TCP sender will simply discard any D-SACK blocks, and process the other SACK blocks in the SACK option field as it normally would.
D-SACKの使用は既にSACK能力を交渉したTCP送付者と受信機との別々の交渉を必要としません。 D-SACKのための別々の交渉の欠如は、TCP送付者がこの拡大をSACKに理解していないとTCP受信機がブロックをD-SACKに送るかもしれないことを意味します。 この場合、TCP送付者は、通常、処理するように単にどんなD-SACKブロックも捨てて、SACKオプション・フィールドでの他のSACKブロックを処理するでしょう。
Floyd, et al. Standards Track [Page 2] RFC 2883 SACK Extension July 2000
フロイド、他 RFC2883が拡大2000年7月に略奪する標準化過程[2ページ]
3. The Sack Option Format as defined in RFC 2018
3. RFC2018で定義されるSack Option Format
The SACK option as defined in RFC 2018 is as follows:
RFC2018で定義されるSACKオプションは以下の通りです:
+--------+--------+
| Kind=5 | Length |
+--------+--------+--------+--------+
| Left Edge of 1st Block |
+--------+--------+--------+--------+
| Right Edge of 1st Block |
+--------+--------+--------+--------+
| |
/ . . . /
| |
+--------+--------+--------+--------+
| Left Edge of nth Block |
+--------+--------+--------+--------+
| Right Edge of nth Block |
+--------+--------+--------+--------+
+--------+--------+ | 種類=5| 長さ| +--------+--------+--------+--------+ | 最初のブロックの左の縁| +--------+--------+--------+--------+ | 最初のブロックの正しい縁| +--------+--------+--------+--------+ | | / . . . / | | +--------+--------+--------+--------+ | n番目のBlockのEdgeに残されます。| +--------+--------+--------+--------+ | n番目のBlockの右のEdge| +--------+--------+--------+--------+
The Selective Acknowledgement (SACK) option in the TCP header contains a number of SACK blocks, where each block specifies the left and right edge of a block of data received at the TCP receiver. In particular, a block represents a contiguous sequence space of data received and queued at the receiver, where the "left edge" of the block is the first sequence number of the block, and the "right edge" is the sequence number immediately following the last sequence number of the block.
TCPヘッダーのSelective Acknowledgement(SACK)オプションは多くのSACKブロックを含んでいます。(そこでは、各ブロックがTCP受信機に受け取られた1ブロックのデータの左右の縁を指定します)。特に、ブロックはブロックの「左の縁」がブロックの最初の一連番号であり、「正しい縁」がすぐにブロックの最後の一連番号に続く一連番号である受信機に受け取られて、列に並ばせられたデータの隣接の系列スペースを表します。
RFC 2018 implies that the first SACK block specify the segment that triggered the acknowledgement. From RFC 2018, when the data receiver chooses to send a SACK option, "the first SACK block ... MUST specify the contiguous block of data containing the segment which triggered this ACK, unless that segment advanced the Acknowledgment Number field in the header."
RFC2018は、最初のSACKブロックが承認の引き金となったセグメントを指定するのを含意します。 RFC2018年から、SACKオプション、「最初のSACKブロック」を送ってください…(その時、データ受信装置は選びます)。 「そのセグメントがヘッダーのAcknowledgment Number野原を進めなかったならこのACKの引き金となったセグメントを含むデータの隣接のブロックを指定しなければなりません。」
However, RFC 2018 does not address the use of the SACK option when acknowledging a duplicate segment. For example, RFC 2018 specifies that "each block represents received bytes of data that are contiguous and isolated". RFC 2018 further specifies that "if sent at all, SACK options SHOULD be included in all ACKs which do not ACK the highest sequence number in the data receiver's queue." RFC 2018 does not specify the use of the SACK option when a duplicate segment is received, and the cumulative acknowledgement field in the ACK acknowledges all of the data in the data receiver's queue.
しかしながら、写しセグメントを承認するとき、RFC2018はSACKオプションの使用を記述しません。 例えば、RFC2018は、「各ブロックは容認されたバイトの隣接の、そして、孤立しているデータを表します。」と指定します。 RFC2018は、「少しでも送るなら、SACKは含まれているコネがすべて、どんなデータ受信装置の待ち行列で最も高い一連番号のACKもしないACKsであったならSHOULDにゆだねます。」とさらに指定します。 写しセグメントが受け取られているとき、RFC2018はSACKオプションの使用を指定しません、そして、ACKの累積している承認分野はデータ受信装置の待ち行列におけるデータのすべてを承認します。
Floyd, et al. Standards Track [Page 3] RFC 2883 SACK Extension July 2000
フロイド、他 RFC2883が拡大2000年7月に略奪する標準化過程[3ページ]
4. Use of the SACK option for reporting a duplicate segment
4. SACKオプションの写しセグメントを報告する使用
This section specifies the use of SACK blocks when the SACK option is used in reporting a duplicate segment. When D-SACK is used, the first block of the SACK option should be a D-SACK block specifying the sequence numbers for the duplicate segment that triggers the acknowledgement. If the duplicate segment is part of a larger block of non-contiguous data in the receiver's data queue, then the following SACK block should be used to specify this larger block. Additional SACK blocks can be used to specify additional non- contiguous blocks of data, as specified in RFC 2018.
SACKオプションが写しセグメントを報告する際に使用されるとき、このセクションはSACKブロックの使用を指定します。 D-SACKが使用されているとき、SACKオプションの最初のブロックは承認の引き金となる写しセグメントに一連番号を指定するD-SACKブロックであるべきです。 写しセグメントが受信機のデータ待ち行列における非隣接のデータの、より大きいブロックの一部であるなら、以下のSACKブロックは、このより大きいブロックを指定するのに使用されるべきです。 追加非隣接のブロックのデータを指定するのにRFC2018で指定されるように追加SACKブロックを使用できます。
The guidelines for reporting duplicate segments are summarized below:
写しセグメントを報告するためのガイドラインは以下へまとめられます:
(1) A D-SACK block is only used to report a duplicate contiguous sequence of data received by the receiver in the most recent packet.
(1) D-SACKブロックは、データの隣接の系列が最新のパケットに受信機で受け取った写しを報告するのに使用されるだけです。
(2) Each duplicate contiguous sequence of data received is reported in at most one D-SACK block. (I.e., the receiver sends two identical D-SACK blocks in subsequent packets only if the receiver receives two duplicate segments.)
(2) データの隣接の系列が受け取った各写しは高々1つのD-SACKブロックで報告されます。 (受信機が2つの写しセグメントを受ける場合にだけ、すなわち、受信機はその後のパケットでの2つの同じD-SACKブロックを送ります。)
(3) The left edge of the D-SACK block specifies the first sequence number of the duplicate contiguous sequence, and the right edge of the D-SACK block specifies the sequence number immediately following the last sequence in the duplicate contiguous sequence.
(3) D-SACKブロックの左の縁は写しの隣接の系列の最初の一連番号を指定します、そして、すぐに写しの隣接の系列における最後の順序に従って、D-SACKブロックの正しい縁は一連番号を指定します。
(4) If the D-SACK block reports a duplicate contiguous sequence from a (possibly larger) block of data in the receiver's data queue above the cumulative acknowledgement, then the second SACK block in that SACK option should specify that (possibly larger) block of data.
(4) D-SACKブロックが累積している承認を超えて受信機のデータ待ち行列におけるデータの(ことによるとより大きい)のブロックから写しの隣接の系列を報告するなら、そのSACKオプションにおける2番目のSACKブロックはデータのその(ことによるとより大きい)のブロックを指定するはずです。
(5) Following the SACK blocks described above for reporting duplicate segments, additional SACK blocks can be used for reporting additional blocks of data, as specified in RFC 2018.
(5) 写しセグメントを報告するために上で説明されたSACKブロックに従って、追加ブロックのデータを報告するのに追加SACKブロックを使用できます、RFC2018で指定されるように。
Note that because each duplicate segment is reported in only one ACK packet, information about that duplicate segment will be lost if that ACK packet is dropped in the network.
そのACKパケットがネットワークで落とされるとそれぞれの写しセグメントが1つのACKパケットだけで報告されるのでその写しセグメントの情報が失われることに注意してください。
4.1 Reporting Full Duplicate Segments
4.1 完全な写しセグメントを報告すること。
We illustrate these guidelines with three examples. In each example, we assume that the data receiver has first received eight segments of 500 bytes each, and has sent an acknowledgement with the cumulative acknowledgement field set to 4000 (assuming the first sequence number is zero). The D-SACK block is underlined in each example.
私たちは3つの例をこれらのガイドラインに入れます。 各例では、私たちは、データ受信装置が最初に8つのセグメントを受けたとそれぞれ500バイトを思って、4000に設定された累積している承認分野と共に承認を送りました(最初の一連番号を仮定するのは、ゼロです)。 D-SACKブロックは各例でアンダーラインを引かれます。
Floyd, et al. Standards Track [Page 4] RFC 2883 SACK Extension July 2000
フロイド、他 RFC2883が拡大2000年7月に略奪する標準化過程[4ページ]
4.1.1. Example 1: Reporting a duplicate segment.
4.1.1. 例1: 写しセグメントを報告します。
Because several ACK packets are lost, the data sender retransmits packet 3000-3499, and the data receiver subsequently receives a duplicate segment with sequence numbers 3000-3499. The receiver sends an acknowledgement with the cumulative acknowledgement field set to 4000, and the first, D-SACK block specifying sequence numbers 3000-3500.
いくつかのACKパケットが無くなるので、データ送付者はパケット3000-3499を再送します、そして、データ受信装置は次に、一連番号3000-3499で写しセグメントを受けます。 受信機は4000に設定された累積している承認分野、および1番目、D-SACKブロック指定一連番号3000-3500がある承認を送ります。
Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
伝えられた容認されたACKはセグメントセグメントを送りました。(袋のブロックを含んでいます)
3000-3499 3000-3499 3500 (ACK dropped)
3500-3999 3500-3999 4000 (ACK dropped)
3000-3499 3000-3499 4000, SACK=3000-3500
---------
4.1.2. Example 2: Reporting an out-of-order segment and a duplicate
segment.
3000-3499 3000-3499 3500(ACKは低下した) 3500-3999 3500-3999 4000(ACKは低下した)3000-3499 3000-3499 4000、SACK=3000-3500--------- 4.1.2. 例2: 不適切なセグメントと写しセグメントを報告します。
Following a lost data packet, the receiver receives an out-of-order data segment, which triggers the SACK option as specified in RFC 2018. Because of several lost ACK packets, the sender then retransmits a data packet. The receiver receives the duplicate packet, and reports it in the first, D-SACK block:
ロストデータパケットに続いて、受信機はRFC2018で指定されているとして不適切なデータ・セグメントを受けます。(それは、SACKオプションの引き金となります)。 いくつかの無くなっているACKパケットのために、そして、送付者はデータ・パケットを再送します。 受信機は、写しパケットを受けて、1番目、D-SACKブロックでそれを報告します:
Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
伝えられた容認されたACKはセグメントセグメントを送りました。(袋のブロックを含んでいます)
3000-3499 3000-3499 3500 (ACK dropped)
3500-3999 3500-3999 4000 (ACK dropped)
4000-4499 (data packet dropped)
4500-4999 4500-4999 4000, SACK=4500-5000 (ACK dropped)
3000-3499 3000-3499 4000, SACK=3000-3500, 4500-5000
---------
3000-3499 3000-3499 3500(ACKは低下した) 3500-3999 3500-3999 4000(ACKは低下した)4000-4499(データ・パケットは低下した)4500-4999 4500-4999 4000、SACK=4500-5000(ACKは低下した)3000-3499 3000-3499 4000、SACK=3000-3500、4500-5000---------
Floyd, et al. Standards Track [Page 5] RFC 2883 SACK Extension July 2000
フロイド、他 RFC2883が拡大2000年7月に略奪する標準化過程[5ページ]
4.1.3. Example 3: Reporting a duplicate of an out-of-order segment.
4.1.3. 例3: 不適切なセグメントの写しを報告します。
Because of a lost data packet, the receiver receives two out-of-order segments. The receiver next receives a duplicate segment for one of these out-of-order segments:
ロストデータパケットのために、受信機は2つの不適切なセグメントを受けます。 次の受信機はこれらの不適切なセグメントの1つのために写しセグメントを受けます:
Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
伝えられた容認されたACKはセグメントセグメントを送りました。(袋のブロックを含んでいます)
3500-3999 3500-3999 4000
4000-4499 (data packet dropped)
4500-4999 4500-4999 4000, SACK=4500-5000
5000-5499 5000-5499 4000, SACK=4500-5500
(duplicated packet)
5000-5499 4000, SACK=5000-5500, 4500-5500
---------
4.2. Reporting Partial Duplicate Segments
3500-3999 3500-3999 4000 4000-4499(データ・パケットは低下した) 4500-4999 4500-4999 4000、SACK=4500-5000 5000-5499 5000-5499 4000、SACK=4500-5500(パケットをコピーする)5000-5499 4000、SACK=5000-5500、4500-5500--------- 4.2. 部分的な写しセグメントを報告します。
It may be possible that a sender transmits a packet that includes one or more duplicate sub-segments--that is, only part but not all of the transmitted packet has already arrived at the receiver. This can occur when the size of the sender's transmitted segments increases, which can occur when the PMTU increases in the middle of a TCP session, for example. The guidelines in Section 4 above apply to reporting partial as well as full duplicate segments. This section gives examples of these guidelines when reporting partial duplicate segments.
送付者が1つ以上の写しサブセグメントを含んでいるパケットを伝えるのは、可能であるかもしれません--伝えられたパケットのすべてではなく、すなわち、部分だけが既に受信機に到着しました。送付者のサイズがセグメント増加(PMTUが例えば、TCPセッションの途中を増やすとき、起こることができる)を伝えたとき、これは起こることができます。 上のセクション4のガイドラインは部分的で完全な写しセグメントを報告するのに適用されます。 部分的な写しセグメントを報告するとき、このセクションはこれらのガイドラインに関する例を出します。
When the SACK option is used for reporting partial duplicate segments, the first D-SACK block reports the first duplicate sub- segment. If the data packet being acknowledged contains multiple partial duplicate sub-segments, then only the first such duplicate sub-segment is reported in the SACK option. We illustrate this with the examples below.
SACKオプションが部分的な写しセグメントを報告するのに使用されるとき、最初のD-SACKブロックは、最初の写しがサブセグメントであると報告します。 承認されるデータ・パケットが複数の部分的な写しサブセグメントを含んでいるなら、最初のそのような写しサブセグメントだけがSACKオプションで報告されます。 私たちは以下の例をこれに入れます。
4.2.1. Example 4: Reporting a single duplicate subsegment.
4.2.1. 例4: 単一の写し「副-セグメント」を報告します。
The sender increases the packet size from 500 bytes to 1000 bytes. The receiver subsequently receives a 1000-byte packet containing one 500-byte subsegment that has already been received and one which has not. The receiver reports only the already received subsegment using a single D-SACK block.
送付者はパケットサイズを500バイトから1000バイトまで増加させます。 既に受け取られた1つの500バイトの「副-セグメント」とそうしていないものを含んでいて、受信機は次に、1000年のバイトのパケットを受けます。 受信機は、1つのD-SACKブロックを使用することで既に容認された「副-セグメント」だけを報告します。
Floyd, et al. Standards Track [Page 6] RFC 2883 SACK Extension July 2000
フロイド、他 RFC2883が拡大2000年7月に略奪する標準化過程[6ページ]
Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
伝えられた容認されたACKはセグメントセグメントを送りました。(袋のブロックを含んでいます)
500-999 500-999 1000
1000-1499 (delayed)
1500-1999 (data packet dropped)
2000-2499 2000-2499 1000, SACK=2000-2500
1000-2000 1000-1499 1500, SACK=2000-2500
1000-2000 2500, SACK=1000-1500
---------
500-999 500-999 1000 1000-1499(延着する)1500-1999(データ・パケットは低下した)2000-2499 2000-2499 1000、SACK=2000-2500 1000-2000 1000-1499 1500、SACK=2000-2500 1000-2000 2500、SACK=1000-1500---------
4.2.2. Example 5: Two non-contiguous duplicate subsegments covered by
the cumulative acknowledgement.
4.2.2. 例5: 累積している承認で覆われた2の非隣接の写し「副-セグメント」。
After the sender increases its packet size from 500 bytes to 1500 bytes, the receiver receives a packet containing two non-contiguous duplicate 500-byte subsegments which are less than the cumulative acknowledgement field. The receiver reports the first such duplicate segment in a single D-SACK block.
送付者がパケットサイズを500バイトから1500バイトまで増加させた後に、受信機は累積している承認分野以下である2の非隣接の写しの500バイトの「副-セグメント」を含むパケットを受けます。 受信機は独身のD-SACKのそのような写しセグメントが妨げる1番目を報告します。
Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
伝えられた容認されたACKはセグメントセグメントを送りました。(袋のブロックを含んでいます)
500-999 500-999 1000
1000-1499 (delayed)
1500-1999 (data packet dropped)
2000-2499 (delayed)
2500-2999 (data packet dropped)
3000-3499 3000-3499 1000, SACK=3000-3500
1000-2499 1000-1499 1500, SACK=3000-3500
2000-2499 1500, SACK=2000-2500, 3000-3500
1000-2499 2500, SACK=1000-1500, 3000-3500
---------
500-999 500-999 1000 1000-1499(延着する)1500-1999(データ・パケットは低下した)2000-2499(延着する)2500-2999(データ・パケットは低下した)3000-3499 3000-3499 1000、SACK=3000-3500 1000-2499 1000-1499 1500、SACK=3000-3500 2000-2499 1500、SACK=2000-2500、3000-3500 1000-2499 2500、SACK=1000-1500、3000-3500---------
4.2.3. Example 6: Two non-contiguous duplicate subsegments not covered
by the cumulative acknowledgement.
4.2.3. 例6: 累積している承認で覆われなかった2の非隣接の写し「副-セグメント」。
This example is similar to Example 5, except that after the sender increases the packet size, the receiver receives a packet containing two non-contiguous duplicate subsegments which are above the cumulative acknowledgement field, rather than below. The first, D- SACK block reports the first duplicate subsegment, and the second, SACK block reports the larger block of non-contiguous data that it belongs to.
この例はExample5と同様です、送付者がパケットサイズを増加させた後に受信機が以下であるよりむしろ累積している承認分野の上にある2つの非隣接の写し「副-セグメント」を含むパケットを受けるのを除いて。 1番目、D SACKブロックは最初の写し「副-セグメント」、および2番目を報告して、SACKブロックはそれが属す非隣接のデータの、より大きいブロックを報告します。
Floyd, et al. Standards Track [Page 7] RFC 2883 SACK Extension July 2000
フロイド、他 RFC2883が拡大2000年7月に略奪する標準化過程[7ページ]
Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
伝えられた容認されたACKはセグメントセグメントを送りました。(袋のブロックを含んでいます)
500-999 500-999 1000
1000-1499 (data packet dropped)
1500-1999 (delayed)
2000-2499 (data packet dropped)
2500-2999 (delayed)
3000-3499 (data packet dropped)
3500-3999 3500-3999 1000, SACK=3500-4000
1000-1499 (data packet dropped)
1500-2999 1500-1999 1000, SACK=1500-2000, 3500-4000
2000-2499 1000, SACK=2000-2500, 1500-2000,
3500-4000
1500-2999 1000, SACK=1500-2000, 1500-3000,
---------
3500-4000
500-999 500-999 1000 1000-1499(データ・パケットは低下しました) 1500-1999(延着する) 2000-2499(データ・パケットは低下した) 2500-2999(延着する)3000-3499(データ・パケットは低下した)3500-3999 3500-3999 1000、SACK=3500-4000 1000-1499(データ・パケットは低下した)1500-2999 1500-1999 1000、SACK=1500-2000、3500-4000 2000-2499 1000、SACK=2000-2500、1500-2000、3500-4000 1500-2999 1000、SACK=1500-2000、1500-3000--------- 3500-4000
4.3. Interaction Between D-SACK and PAWS
4.3. D-袋と足との相互作用
RFC 1323 [RFC1323] specifies an algorithm for Protection Against Wrapped Sequence Numbers (PAWS). PAWS gives a method for distinguishing between sequence numbers for new data, and sequence numbers from a previous cycle through the sequence number space. Duplicate segments might be detected by PAWS as belonging to a previous cycle through the sequence number space.
RFC1323[RFC1323]はProtection Against Wrapped Sequence民数記(PAWS)にアルゴリズムを指定します。 PAWSは新しいデータ、および一連番号のために前の1サイクルから一連番号スペースまで一連番号を見分けるための方法を与えます。 写しセグメントは一連番号スペースを通して前の1サイクルに属するとPAWSによって検出されるかもしれません。
RFC 1323 specifies that for such packets, the receiver should do the following:
RFC1323は、そのようなパケットに関して、受信機が以下をするはずであると指定します:
Send an acknowledgement in reply as specified in RFC 793 page 69,
and drop the segment.
RFC793での指定されるとしての回答における承認に69ページを送ってください、そして、セグメントを落としてください。
Since PAWS still requires sending an ACK, there is no harmful interaction between PAWS and the use of D-SACK. The D-SACK block can be included in the SACK option of the ACK, as outlined in Section 4, independently of the use of PAWS by the TCP receiver, and independently of the determination by PAWS of the validity or invalidity of the data segment.
PAWSが、ACKを送るのをまだ必要としているので、D-SACKのPAWSと使用とのどんな有害な相互作用もありません。 ACKのSACKオプションにD-SACKブロックを含むことができます、セクション4に概説されているように、TCP受信機、正当性のPAWSかデータ・セグメントの無効による決断およびの如何にかかわらずPAWSの使用の如何にかかわらず。
TCP senders receiving D-SACK blocks should be aware that a segment reported as a duplicate segment could possibly have been from a prior cycle through the sequence number space. This is independent of the use of PAWS by the TCP data receiver. We do not anticipate that this will present significant problems for senders using D-SACK information.
D-SACKブロックを受け取るTCP送付者は先のサイクルから一連番号スペースまで写しセグメントがあったかもしれないのでセグメントが報告したのを意識しているべきです。 これはTCPデータ受信装置でPAWSの使用から独立しています。私たちは、これが送付者のためにD-SACK情報を使用することで重大な問題を提示すると予期しません。
Floyd, et al. Standards Track [Page 8] RFC 2883 SACK Extension July 2000
フロイド、他 RFC2883が拡大2000年7月に略奪する標準化過程[8ページ]
5. Detection of Duplicate Packets
5. 写しパケットの検出
This extension to the SACK option enables the receiver to accurately report the reception of duplicate data. Because each receipt of a duplicate packet is reported in only one ACK packet, the loss of a single ACK can prevent this information from reaching the sender. In addition, we note that the sender can not necessarily trust the receiver to send it accurate information [SCWA99].
SACKオプションへのこの拡大は、受信機が正確に重複データのレセプションを報告するのを可能にします。 写しパケットの各領収書が1つのACKパケットだけで報告されるので、独身のACKの損失によって、この情報は送付者が届くことができません。 さらに、私たちは、送付者が的確な情報[SCWA99]をそれに送るために必ず受信機を信じることができるというわけではないことに注意します。
In order for the sender to check that the first (D)SACK block of an acknowledgement in fact acknowledges duplicate data, the sender should compare the sequence space in the first SACK block to the cumulative ACK which is carried IN THE SAME PACKET. If the SACK sequence space is less than this cumulative ACK, it is an indication that the segment identified by the SACK block has been received more than once by the receiver. An implementation MUST NOT compare the sequence space in the SACK block to the TCP state variable snd.una (which carries the total cumulative ACK), as this may result in the wrong conclusion if ACK packets are reordered.
送付者が、事実上、承認のSACKブロックが承認する最初の(D)がデータをコピーするのをチェックするように、送付者は最初のSACKブロックの系列スペースを運ばれたIN THE SAME PACKETである累積しているACKと比較するべきです。 SACK系列スペースがこの累積しているACK以下であるなら、それは受信機による一度よりSACKブロックによって特定されたセグメントをもう少し受け取ったという指示です。実現はTCP州の可変snd.una(総累積しているACKを運ぶ)とSACKブロックの系列スペースを比較してはいけません、ACKパケットが再命令されるならこれが間違った結論をもたらしているかもしれない間。
If the sequence space in the first SACK block is greater than the cumulative ACK, then the sender next compares the sequence space in the first SACK block with the sequence space in the second SACK block, if there is one. This comparison can determine if the first SACK block is reporting duplicate data that lies above the cumulative ACK.
最初のSACKブロックの系列スペースが累積しているACKより大きいなら、次の送付者は2番目のSACKブロックの系列スペースに最初のSACKブロックの系列スペースをたとえます、1つがあれば。 この比較は、最初のSACKブロックが累積しているACKの上にある重複データを報告しているかどうか決定できます。
TCP implementations which follow RFC 2581 [RFC2581] could see duplicate packets in each of the following four situations. This document does not specify what action a TCP implementation should take in these cases. The extension to the SACK option simply enables the sender to detect each of these cases. Note that these four conditions are not an exhaustive list of possible cases for duplicate packets, but are representative of the most common/likely cases. Subsequent documents will describe experimental proposals for sender responses to the detection of unnecessary retransmits due to reordering, lost ACKS, or early retransmit timeouts.
RFC2581[RFC2581]に続くTCP実現はそれぞれの以下の4つの状況で写しパケットを見るかもしれません。 このドキュメントは、TCP実現がこれらの場合でどんな行動を取るべきであるかを指定しません。 SACKオプションへの拡大は、送付者がそれぞれに関するこれらのケースを検出するのを単に可能にします。 これらの4つの状態が写しパケットのための可能なケースに関する完全なりストではありませんが、最も一般的な/ありそうなケースを代表していることに注意してください。 不要の検出への送付者応答は再命令のため再送されます、無くなっているACKS、またはタイムアウトが早く再送されるので、その後のドキュメントは実験的な提案について説明するでしょう。
Floyd, et al. Standards Track [Page 9] RFC 2883 SACK Extension July 2000
フロイド、他 RFC2883が拡大2000年7月に略奪する標準化過程[9ページ]
5.1. Replication by the network
5.1. ネットワークによる模写
If a packet is replicated in the network, this extension to the SACK option can identify this. For example:
パケットがネットワークで模写されるなら、SACKオプションへのこの拡大はこれを特定できます。 例えば:
Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
伝えられた容認されたACKはセグメントセグメントを送りました。(袋のブロックを含んでいます)
500-999 500-999 1000
1000-1499 1000-1499 1500
(replicated)
1000-1499 1500, SACK=1000-1500
---------
500-999 500-999 1000 1000-1499 1000-1499 1500(模写されます) 1000-1499 1500 =1000-1500を略奪してください。---------
In this case, the second packet was replicated in the network. An ACK containing a D-SACK block which is lower than its ACK field and is not identical to a previously retransmitted segment is indicative of a replication by the network.
この場合、2番目のパケットはネットワークで模写されました。 ACK分野より低い、そして、以前に再送されたセグメントと同じでないD-SACKブロックを含むACKはネットワークによる模写を暗示しています。
WITHOUT D-SACK:
D-袋なしで:
If D-SACK was not used and the last ACK was piggybacked on a data packet, the sender would not know that a packet had been replicated in the network. If D-SACK was not used and neither of the last two ACKs was piggybacked on a data packet, then the sender could reasonably infer that either some data packet *or* the final ACK packet had been replicated in the network. The receipt of the D-SACK packet gives the sender positive knowledge that this data packet was replicated in the network (assuming that the receiver is not lying).
D-SACKが使用されないで、最後のACKがデータ・パケットの上で背負われるなら、送付者は、パケットがネットワークで模写されたのを知らないでしょうに。 *D-SACKが使用されないで、また最後の2ACKsのどちらもデータ・パケットの上で背負われないなら、送付者が合理的にいくらかのデータ・パケット*を推論そんなにのどちらかであることができるでしょうにか、または最終的なACKパケットはネットワークで模写されました。 D-SACKパケットの領収書はこのデータ・パケットがネットワークで模写されたという(受信機がないと仮定して)送付者の積極的な知識を与えます。
RESEARCH ISSUES:
問題について研究してください:
The current SACK option already allows the sender to identify duplicate ACKs that do not acknowledge new data, but the D-SACK option gives the sender a stronger basis for inferring that a duplicate ACK does not acknowledge new data. The knowledge that a duplicate ACK does not acknowledge new data allows the sender to refrain from using that duplicate ACKs to infer packet loss (e.g., Fast Retransmit) or to send more data (e.g., Fast Recovery).
送付者は現在のSACKオプションで既に新しいデータを承認しない写しACKsを特定できますが、D-SACKオプションは写しACKが新しいデータを承認しないと推論するより強い基礎を送付者に与えます。 写しACKが新しいデータを承認しないという知識で、送付者は、パケット損失(例えば、Fast Retransmit)を推論するか、または、より多くのデータ(例えば、Fast Recovery)を送るのにその写しACKsを使用するのを控えることができます。
5.2. False retransmit due to reordering
5.2. 偽は再命令のため再送されます。
If packets are reordered in the network such that a segment arrives more than 3 packets out of order, TCP's Fast Retransmit algorithm will retransmit the out-of-order packet. An example of this is shown below:
パケットがセグメントが3パケットより故障していた状態で到着して、TCPのFast Retransmitがアルゴリズムであるようにものがそうするネットワークで再命令されるなら、故障しているパケットを再送してください。 この例は以下に示されます:
Floyd, et al. Standards Track [Page 10] RFC 2883 SACK Extension July 2000
フロイド、他 RFC2883が拡大2000年7月に略奪する標準化過程[10ページ]
Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
伝えられた容認されたACKはセグメントセグメントを送りました。(袋のブロックを含んでいます)
500-999 500-999 1000
1000-1499 (delayed)
1500-1999 1500-1999 1000, SACK=1500-2000
2000-2499 2000-2499 1000, SACK=1500-2500
2500-2999 2500-2999 1000, SACK=1500-3000
1000-1499 1000-1499 3000
1000-1499 3000, SACK=1000-1500
---------
500-999 500-999 1000 1000-1499(延着します) 1500-1999 1500-1999 1000 =1500-2000 2000-2499 2000-2499 1000を略奪してください、袋=1500-2500 2500-2999 2500-2999 1000、袋=1500-3000 1000-1499 1000-1499 3000 1000-1499 3000、袋の=1000-1500---------
In this case, an ACK containing a SACK block which is lower than its ACK field and identical to a previously retransmitted segment is indicative of a significant reordering followed by a false (unnecessary) retransmission.
この場合、ACK分野より低くて、以前に再送されたセグメントと同じSACKブロックを含むACKは偽(不要な)の「再-トランスミッション」によって続かれた重要な再命令を暗示しています。
WITHOUT D-SACK:
D-袋なしで:
With the use of D-SACK illustrated above, the sender knows that either the first transmission of segment 1000-1499 was delayed in the network, or the first transmission of segment 1000-1499 was dropped and the second transmission of segment 1000-1499 was duplicated. Given that no other segments have been duplicated in the network, this second option can be considered unlikely.
D-SACKの使用が上で例証されている状態で、送付者は、セグメント1000-1499の最初の送信がネットワークで遅れたか、セグメント1000-1499の最初の送信が落とされて、またはセグメント1000-1499の2番目の送信がコピーされたのを知っています。 他のセグメントが全くネットワークでコピーされていないなら、ありそうもないとこの2番目のオプションを考えることができます。
Without the use of D-SACK, the sender would only know that either the first transmission of segment 1000-1499 was delayed in the network, or that either one of the data segments or the final ACK was duplicated in the network. Thus, the use of D-SACK allows the sender to more reliably infer that the first transmission of segment 1000-1499 was not dropped.
D-SACKの使用がなければ、送付者は、セグメント1000-1499の最初の送信がネットワークで遅れたか、またはデータ・セグメントか最終的なACKのそのどちらかがネットワークでコピーされたのを知っているだけでしょう。 したがって、D-SACKの使用で、送付者は、セグメント1000-1499の最初の送信が落とされなかったと、より確かに推論できます。
[AP99], [L99], and [LK00] note that the sender could unambiguously detect an unnecessary retransmit with the use of the timestamp option. [LK00] proposes a timestamp-based algorithm that minimizes the penalty for an unnecessary retransmit. [AP99] proposes a heuristic for detecting an unnecessary retransmit in an environment with neither timestamps nor SACK. [L99] also proposes a two-bit field as an alternate to the timestamp option for unambiguously marking the first three retransmissions of a packet. A similar idea was proposed in [ISO8073].
送付者が明白に検出できた[AP99]、[L99]、および[LK00]注意、不要である、タイムスタンプオプションの使用で、再送してください。 [LK00]がそれが刑罰を最小にするタイムスタンプベースのアルゴリズムを提案する、不要である、再送してください。 [AP99]が検出のためにヒューリスティックを提案する、不要である、どちらもタイムスタンプかSACKがある環境で、再送してください。 また、[L99]は補欠として明白にパケットの最初の3「再-トランスミッション」をマークするためのタイムスタンプオプションに安っぽい分野を提案します。 同様の考えは[ISO8073]で提案されました。
RESEARCH ISSUES:
問題について研究してください:
The use of D-SACK allows the sender to detect some cases (e.g., when no ACK packets have been lost) when a a Fast Retransmit was due to packet reordering instead of packet loss. This allows the TCP sender
Fast Retransmitがパケット損失の代わりに再命令されるパケットのためであったときに、D-SACKの使用で、送付者はいくつかのケースを検出できます(例えば、ACKパケットは全くいつ失われていませんか)。 これはTCP送付者を許容します。
Floyd, et al. Standards Track [Page 11] RFC 2883 SACK Extension July 2000
フロイド、他 RFC2883が拡大2000年7月に略奪する標準化過程[11ページ]
to adjust the duplicate acknowledgment threshold, to prevent such unnecessary Fast Retransmits in the future. Coupled with this, when the sender determines, after the fact, that it has made an unnecessary window reduction, the sender has the option of "undoing" that reduction in the congestion window by resetting ssthresh to the value of the old congestion window, and slow-starting until the congestion window has reached that point.
写し承認敷居を調整して、将来そのような不要なFast Retransmitsを防ぐために。 これと結合されています、送付者が、事実の後に不要な窓の減少をしたと決心していると、送付者は混雑ウィンドウに混雑ウィンドウがそのポイントに達するまでの古い混雑ウィンドウ、および遅い始めの値にssthreshをリセットすることによって、その減少の「元に戻す」であるオプションを持っています。
Any proposal for "undoing" a reduction in the congestion window would have to address the possibility that the TCP receiver could be lying in its reports of received packets [SCWA99].
混雑ウィンドウでの減少の「元に戻す」であるためのどんな提案もTCP受信機が容認されたパケット[SCWA99]のレポートにあることができた可能性を記述しなければならないでしょう。
5.3. Retransmit Timeout Due to ACK Loss
5.3. ACKの損失によるタイムアウトを再送してください。
If an entire window of ACKs is lost, a timeout will result. An example of this is given below:
ACKsの全体の窓が無くなると、タイムアウトは結果として生じるでしょう。 この例は以下に出されます:
Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
伝えられた容認されたACKはセグメントセグメントを送りました。(袋のブロックを含んでいます)
500-999 500-999 1000 (ACK dropped)
1000-1499 1000-1499 1500 (ACK dropped)
1500-1999 1500-1999 2000 (ACK dropped)
2000-2499 2000-2499 2500 (ACK dropped)
(timeout)
500-999 500-999 2500, SACK=500-1000
--------
500-999 500-999 1000(ACKは低下した)1000-1499 1000-1499 1500(ACKは低下した)1500-1999 1500-1999 2000(ACKは低下した)2000-2499 2000-2499 2500(ACKは低下した)(タイムアウト)500-999 500-999 2500、SACK=500-1000--------
In this case, all of the ACKs are dropped, resulting in a timeout. This condition can be identified because the first ACK received following the timeout carries a D-SACK block indicating duplicate data was received.
この場合、タイムアウトをもたらして、ACKsのすべてが落とされます。 タイムアウトに続いて、受け取られた最初のACKが重複データが受け取られたのを示すD-SACKブロックを運ぶので、この状態を特定できます。
WITHOUT D-SACK:
D-袋なしで:
Without the use of D-SACK, the sender in this case would be unable to decide that no data packets has been dropped.
D-SACKの使用がなければ、この場合、送付者は、データ・パケットが全く落とされていないと決めることができないでしょう。
RESEARCH ISSUES:
問題について研究してください:
For a TCP that implements some form of ACK congestion control [BPK97], this ability to distinguish between dropped data packets and dropped ACK packets would be particularly useful. In this case, the connection could implement congestion control for the return (ACK) path independently from the congestion control on the forward (data) path.
何らかの形式のACK輻輳制御[BPK97]を実行するTCPに、低下しているデータ・パケットと低下しているACKパケットを見分けるこの能力は特に役に立つでしょう。 この場合、接続は前進の(データ)経路における輻輳制御からリターン(ACK)経路のための輻輳制御を独自に実行できました。
Floyd, et al. Standards Track [Page 12] RFC 2883 SACK Extension July 2000
フロイド、他 RFC2883が拡大2000年7月に略奪する標準化過程[12ページ]
5.4. Early Retransmit Timeout
5.4. 早く、タイムアウトは再送されます。
If the sender's RTO is too short, an early retransmission timeout can occur when no packets have in fact been dropped in the network. An example of this is given below:
パケットが全くネットワークで事実上落とされていないとき、送付者のRTOが短過ぎるなら、早い再送タイムアウトは起こることができます。 この例は以下に出されます:
Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
伝えられた容認されたACKはセグメントセグメントを送りました。(袋のブロックを含んでいます)
500-999 (delayed)
1000-1499 (delayed)
1500-1999 (delayed)
2000-2499 (delayed)
(timeout)
500-999 (delayed)
500-999 1000
1000-1499 (delayed)
1000-1499 1500
...
1500-1999 2000
2000-2499 2500
500-999 2500, SACK=500-1000
--------
1000-1499 2500, SACK=1000-1500
---------
...
500-999(延着する)1000-1499(延着する)1500-1999(延着する)2000-2499(延着します)(タイムアウト)500-999(延着する)500-999 1000 1000-1499(延着します)1000-1499 1500… 1500-1999 2000 2000-2499 2500 500-999 2500、袋の=500-1000-------- 1000-1499 2500 =1000-1500を略奪してください。--------- ...
In this case, the first packet is retransmitted following the timeout. Subsequently, the original window of packets arrives at the receiver, resulting in ACKs for these segments. Following this, the retransmissions of these segments arrive, resulting in ACKs carrying SACK blocks which identify the duplicate segments.
この場合、タイムアウトに続いて、最初のパケットは再送されます。 次に、これらのセグメントのためのACKsをもたらして、パケットのオリジナルの窓は受信機に届きます。 これに続いて、写しセグメントを特定するSACKブロックを運ぶACKsをもたらして、これらのセグメントの「再-トランスミッション」は届きます。
This can be identified as an early retransmission timeout because the ACK for byte 1000 is received after the timeout with no SACK information, followed by an ACK which carries SACK information (500- 999) indicating that the retransmitted segment had already been received.
タイムアウトの後に再送されたセグメントが既に受け取られたのを示しながらSACK情報(500- 999)を運ぶACKによって従われたSACK情報なしでバイト1000ACKを受け取るので、早い再送タイムアウトとしてこれを特定できます。
WITHOUT D-SACK:
D-袋なしで:
If D-SACK was not used and one of the duplicate ACKs was piggybacked on a data packet, the sender would not know how many duplicate packets had been received. If D-SACK was not used and none of the duplicate ACKs were piggybacked on a data packet, then the sender would have sent N duplicate packets, for some N, and received N duplicate ACKs. In this case, the sender could reasonably infer that
D-SACKが使用されないで、写しACKsの1つがデータ・パケットの上で背負われるなら、送付者は、いくつがパケットをコピーするかが受け取られたのを知らないでしょうに。 D-SACKが使用されないで、また写しACKsのいずれもデータ・パケットの上で背負われなかったなら、送付者は、いくつかのNのためにN写しパケットを送って、N写しACKsを受け取ったでしょう。 この場合、送付者は合理的にそれを推論できました。
Floyd, et al. Standards Track [Page 13] RFC 2883 SACK Extension July 2000
フロイド、他 RFC2883が拡大2000年7月に略奪する標準化過程[13ページ]
some data or ACK packet had been replicated in the network, or that an early retransmission timeout had occurred (or that the receiver is lying).
あるデータかACKパケットがネットワークで模写されたか、または早い再送タイムアウトが起こった、(または、受信機があります)
RESEARCH ISSUES:
問題について研究してください:
After the sender determines that an unnecessary (i.e., early) retransmit timeout has occurred, the sender could adjust parameters for setting the RTO, to prevent more unnecessary retransmit timeouts. Coupled with this, when the sender determines, after the fact, that it has made an unnecessary window reduction, the sender has the option of "undoing" that reduction in the congestion window.
再送してください。送付者がそれを決定した後、不要(すなわち、早い)である、タイムアウトは起こって、送付者はRTOを設定するためのパラメタを調整できて、不要な状態で以上を防ぐために、タイムアウトを再送してください。 これと結合されています、送付者が、事実の後に不要な窓の減少をしたと決心していると、送付者は混雑ウィンドウにその減少の「元に戻す」であるオプションを持っています。
6. Security Considerations
6. セキュリティ問題
This document neither strengthens nor weakens TCP's current security properties.
このドキュメントは、TCPの現在のセキュリティの特性を強化でない、また弱めません。
7. Acknowledgements
7. 承認
We would like to thank Mark Handley, Reiner Ludwig, and Venkat Padmanabhan for conversations on these issues, and to thank Mark Allman for helpful feedback on this document.
マーク・ハンドレー、ライナー・ラドウィグ、およびヴェンカトPadmanabhanがこれらの問題における会話、このドキュメントの役立っているフィードバックについてマーク・オールマンに感謝するのを感謝申し上げます。
8. References
8. 参照
[AP99] Mark Allman and Vern Paxson, On Estimating End-to-End
Network Path Properties, SIGCOMM 99, August 1999. URL
"http://www.acm.org/sigcomm/sigcomm99/papers/session7-
3.html".
[AP99]は1999年8月に終わりから終わりへのネットワーク経路特性、SIGCOMM99を見積もっているときオールマンとバーン・パクソンをマークします。 URL「 http://www.acm.org/sigcomm/sigcomm99/papers/session7- 3.html。」
[BPS99] J.C.R. Bennett, C. Partridge, and N. Shectman, Packet
Reordering is Not Pathological Network Behavior, IEEE/ACM
Transactions on Networking, Vol. 7, No. 6, December 1999,
pp. 789-798.
[BPS99]J.C.R.ベネット、C.Partridge、およびN.Shectman、Packet ReorderingはNot Pathological Network Behaviorです、Networkingの上のIEEE/ACM Transactions、Vol.7、No.6、1999年12月、ページ 789-798.
[BPK97] Hari Balakrishnan, Venkata Padmanabhan, and Randy H. Katz,
The Effects of Asymmetry on TCP Performance, Third ACM/IEEE
Mobicom Conference, Budapest, Hungary, Sep 1997. URL
"http://www.cs.berkeley.edu/~padmanab/
index.html#Publications".
[BPK97] TCPパフォーマンス、第3ACM/IEEE Mobicomコンファレンス(ブダペスト(ハンガリー)1997年9月)へのハーリBalakrishnan、Venkata Padmanabhanとランディ・H.キャッツ、非対称の効果。 「 http://www.cs.berkeley.edu/~padmanab/ index.html#刊行物」というURL。
[F99] Floyd, S., Re: TCP and out-of-order delivery, Message ID
<199902030027.QAA06775@owl.ee.lbl.gov> to the end-to-end-
interest mailing list, February 1999. URL
"http://www.aciri.org/floyd/notes/TCP_Feb99.email".
[F99] フロイド、S.、Re: TCPと不適切な配送、Message ID <199902030027.QAA06775@owl.ee.lbl.gov 、gt;、終わりから終わり関心へのメーリングリスト、2月1999 URL" http://www.aciri.org/floyd/notes/TCP_Feb99.email "。
Floyd, et al. Standards Track [Page 14] RFC 2883 SACK Extension July 2000
フロイド、他 RFC2883が拡大2000年7月に略奪する標準化過程[14ページ]
[ISO8073] ISO/IEC, Information-processing systems - Open Systems
Interconnection - Connection Oriented Transport Protocol
Specification, Internation Standard ISO/IEC 8073, December
1988.
[ISO8073]ISO/IEC、情報処理システム--オープン・システム・インターコネクション--接続Oriented TransportプロトコルSpecification、1988年12月のInternation Standard ISO/IEC8073。
[L99] Reiner Ludwig, A Case for Flow Adaptive Wireless links,
Technical Report UCB//CSD-99-1053, May 1999. URL
"http://iceberg.cs.berkeley.edu/papers/Ludwig-
FlowAdaptive/".
Technical Report UCB//CSD-99-1053、[L99]ライナー・ラドウィグ、Flow Adaptive WirelessのためのA Caseはリンクして、5月は1999です。 URL「 http://iceberg.cs.berkeley.edu/papers/Ludwig- FlowAdaptive/。」
[LK00] Reiner Ludwig and Randy H. Katz, The Eifel Algorithm:
Making TCP Robust Against Spurious Retransmissions, SIGCOMM
Computer Communication Review, V. 30, N. 1, January 2000.
URL "http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-
toc-2000.html".
[LK00]ライナー・ラドウィグとランディ・H.キャッツ、アイフェル高原アルゴリズム: 2000年1月に偽物のRetransmissionsに対して強健なTCP、SIGCOMMコンピュータコミュニケーションレビューをV.30、N.1にします。 URL「 http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr- toc-2000.html。」
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for
High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン(V.、ブレーデン、R. and D.ボーマン、「高性能のためのTCP拡張子」、RFC1323)は1992がそうするかもしれません。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgement Options", RFC 2018, April 1996.
[RFC2018] マシスとM.とMahdaviとJ.とフロイドとS.とA.Romanow、「TCPの選択している承認オプション」、RFC2018、1996年4月。
[RFC2581] Allman, M., Paxson,V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2581] オールマンとM.とパクソンとV.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。
[SCWA99] Stefan Savage, Neal Cardwell, David Wetherall, Tom
Anderson, TCP Congestion Control with a Misbehaving
Receiver, ACM Computer Communications Review, pp. 71-78, V.
29, N. 5, October, 1999. URL
"http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc-
99.html".
[SCWA99] ステファン・サヴェージ、ニール・カードウェル、デヴィッドWetherall、トム・アンダーソン、Misbehaving ReceiverとTCP Congestion Control、ACMコンピュータCommunications Review、ページ 71-78と、V.29、1999年のN.10月5日。 URL「 http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc- 99.html。」
Floyd, et al. Standards Track [Page 15] RFC 2883 SACK Extension July 2000
フロイド、他 RFC2883が拡大2000年7月に略奪する標準化過程[15ページ]
Authors' Addresses
作者のアドレス
Sally Floyd AT&T Center for Internet Research at ICSI (ACIRI)
ICSIでのインターネット調査のためにフロイドAT&Tセンターを出撃させてください。(ACIRI)
Phone: +1 510-666-6989 EMail: floyd@aciri.org URL: http://www.aciri.org/floyd/
以下に電話をしてください。 +1 510-666-6989 メールしてください: floyd@aciri.org URL: http://www.aciri.org/floyd/
Jamshid Mahdavi Novell
Jamshid Mahdaviノベル
Phone: 1-408-967-3806 EMail: mahdavi@novell.com
以下に電話をしてください。 1-408-967-3806 メールしてください: mahdavi@novell.com
Matt Mathis Pittsburgh Supercomputing Center
マットマシスピッツバーグスーパーコンピューティングセンター
Phone: 412 268-3319 EMail: mathis@psc.edu URL: http://www.psc.edu/~mathis/
以下に電話をしてください。 412 268-3319 メールしてください: mathis@psc.edu URL: http://www.psc.edu/~mathis/
Matthew Podolsky UC Berkeley Electrical Engineering & Computer Science Dept.
マシューポドルスキーUCバークレー電気工学とコンピュータサイエンス部
Phone: 510-649-8914 EMail: podolsky@eecs.berkeley.edu URL: http://www.eecs.berkeley.edu/~podolsky
以下に電話をしてください。 510-649-8914 メールしてください: podolsky@eecs.berkeley.edu URL: http://www.eecs.berkeley.edu/~podolsky
Floyd, et al. Standards Track [Page 16] RFC 2883 SACK Extension July 2000
フロイド、他 RFC2883が拡大2000年7月に略奪する標準化過程[16ページ]
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 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機能のための基金は現在、インターネット協会によって提供されます。
Floyd, et al. Standards Track [Page 17]
フロイド、他 標準化過程[17ページ]
一覧
スポンサーリンク
