[要約] RFC 3819は、インターネットサブネットの設計者に対するアドバイスを提供するものであり、効果的なネットワーク設計のためのガイドラインを提供します。その目的は、インターネットのサブネット設計に関する知識を共有し、ネットワークのパフォーマンスとセキュリティを向上させることです。
Network Working Group P. Karn, Ed.
Request for Comments: 3819 Qualcomm
BCP: 89 C. Bormann
Category: Best Current Practice Universitaet Bremen TZI
G. Fairhurst
University of Aberdeen
D. Grossman
Motorola, Inc.
R. Ludwig
Ericsson Research
J. Mahdavi
Novell
G. Montenegro
Sun Microsystems Laboratories, Europe
J. Touch
USC/ISI
L. Wood
Cisco Systems
July 2004
Advice for Internet Subnetwork Designers
インターネットサブネットワークデザイナーへのアドバイス
Status of this Memo
本文書の位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This document provides advice to the designers of digital communication equipment, link-layer protocols, and packet-switched local networks (collectively referred to as subnetworks), who wish to support the Internet protocols but may be unfamiliar with the Internet architecture and the implications of their design choices on the performance and efficiency of the Internet.
このドキュメントは、インターネットプロトコルをサポートしたいと考えているが、インターネットアーキテクチャと不慣れなことと、インターネットアーキテクチャに不慣れなことと、パケット通信機器、リンク層プロトコル、およびパケットスイッチのローカルネットワーク（総称してサブネットワークと呼ばれる）の設計者にアドバイスを提供します。インターネットのパフォーマンスと効率に関する彼らの設計の選択。
Table of Contents
目次
1. Introduction and Overview. . . . . . . . . . . . . . . . . . . 2
2. Maximum Transmission Units (MTUs) and IP Fragmentation . . . . 4
2.1. Choosing the MTU in Slow Networks. . . . . . . . . . . . 6
3. Framing on Connection-Oriented Subnetworks . . . . . . . . . . 7
4. Connection-Oriented Subnetworks. . . . . . . . . . . . . . . . 9
5. Broadcasting and Discovery . . . . . . . . . . . . . . . . . . 10
6. Multicasting . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Bandwidth on Demand (BoD) Subnets. . . . . . . . . . . . . . . 13
8. Reliability and Error Control. . . . . . . . . . . . . . . . . 14
8.1. TCP vs Link-Layer Retransmission . . . . . . . . . . . . 14
8.2. Recovery from Subnetwork Outages . . . . . . . . . . . . 17
8.3. CRCs, Checksums and Error Detection. . . . . . . . . . . 18
8.4. How TCP Works. . . . . . . . . . . . . . . . . . . . . . 20
8.5. TCP Performance Characteristics. . . . . . . . . . . . . 22
8.5.1. The Formulae . . . . . . . . . . . . . . . . . . 22
8.5.2. Assumptions. . . . . . . . . . . . . . . . . . . 23
8.5.3. Analysis of Link-Layer Effects on TCP
Performance. . . . . . . . . . . . . . . . . . . 24
9. Quality-of-Service (QoS) Considerations. . . . . . . . . . . . 26
10. Fairness vs Performance. . . . . . . . . . . . . . . . . . . . 29
11. Delay Characteristics. . . . . . . . . . . . . . . . . . . . . 30
12. Bandwidth Asymmetries. . . . . . . . . . . . . . . . . . . . . 31
13. Buffering, Flow and Congestion Control . . . . . . . . . . . . 31
14. Compression. . . . . . . . . . . . . . . . . . . . . . . . . . 34
15. Packet Reordering. . . . . . . . . . . . . . . . . . . . . . . 36
16. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
17. Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
18. Security Considerations. . . . . . . . . . . . . . . . . . . . 41
19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44
20. Informative References . . . . . . . . . . . . . . . . . . . . 45
21. Contributors' Addresses. . . . . . . . . . . . . . . . . . . . 57
22. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 58
23. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 60
IP, the Internet Protocol [RFC791] [RFC2460], is the core protocol of the Internet. IP defines a simple "connectionless" packet-switched network. The success of the Internet is largely attributed to IP's simplicity, the "end-to-end principle" [SRC81] on which the Internet is based, and the resulting ease of carrying IP on a wide variety of subnetworks, not necessarily designed with IP in mind. A subnetwork refers to any network operating immediately below the IP layer to connect two or more systems using IP (i.e., end hosts or routers). In its simplest form, this may be a direct connection between the IP systems (e.g., using a length of cable or a wireless medium).
IP、インターネットプロトコル[RFC791] [RFC2460]は、インターネットのコアプロトコルです。IPは、単純な「コネクションレス」パケットスイッチネットワークを定義します。インターネットの成功は、IPのシンプルさ、インターネットの基礎となる「エンドツーエンドの原則」[SRC81]、およびIPで設計されているわけではなく、多種多様なサブネットワークにIPを運ぶことのしやすさに大きく起因しています。念頭に置いて。サブネットワークとは、IPレイヤーのすぐ下に動作するネットワークを指し、IP（つまり、エンドホストまたはルーター）を使用して2つ以上のシステムを接続します。最も単純な形式では、これはIPシステム間の直接的な接続である可能性があります（たとえば、ケーブルの長さまたはワイヤレスメディアを使用してください）。
This document defines a subnetwork as a layer 2 network, which is a network that does not rely upon the services of IP routers to forward packets between parts of the subnetwork. However, IP routers may bridge frames at Layer 2 between parts of a subnetwork. Sometimes, it is convenient to aggregate a group of such subnetworks into a single logical subnetwork. IP routing protocols (e.g., OSPF, IS-IS, and PIM) can be configured to support this aggregation, but typically present a layer-3 subnetwork rather than a layer-2 subnetwork. This may also result in a specific packet passing several times over the same layer-2 subnetwork via an intermediate layer-3 gateway (router). Because that aggregation requires layer-3 components, issues thereof are beyond the scope of this document.
このドキュメントでは、サブネットワークをレイヤー2ネットワークとして定義します。レイヤー2ネットワークは、IPルーターのサービスに依存してサブネットワークの一部間でパケットを転送しないネットワークです。ただし、IPルーターは、サブネットワークの部分の間のレイヤー2にフレームをブリッジする場合があります。このようなサブネットワークのグループを単一の論理サブネットワークに集約すると便利な場合があります。IPルーティングプロトコル（OSPF、IS-IS、およびPIMなど）は、この集約をサポートするように構成できますが、通常、レイヤー2サブネットワークではなくレイヤー-3サブネットワークを示します。これにより、特定のパケットが中間層-3ゲートウェイ（ルーター）を介して同じレイヤー2サブネットワークを数回通過する可能性があります。その集約にはレイヤー-3コンポーネントが必要なため、その問題はこのドキュメントの範囲を超えています。
However, while many subnetworks carry IP, they do not necessarily do so with maximum efficiency, minimum complexity, or cost, nor do they implement certain features to efficiently support newer Internet features of increasing importance, such as multicasting or quality of service.
ただし、多くのサブネットワークはIPを運びますが、最大の効率、最小複雑さ、またはコストで必ずしもそうするわけではなく、マルチリキャストやサービス品質など、重要性を高める新しいインターネット機能を効率的にサポートする特定の機能を実装していません。
With the explosive growth of the Internet, IP packets comprise an increasingly large fraction of the traffic carried by the world's telecommunications networks. It therefore makes sense to optimize both existing and new subnetwork technologies for IP as much as possible.
インターネットの爆発的な成長に伴い、IPパケットは、世界の通信ネットワークによって運ばれるトラフィックのますます大部分が構成されています。したがって、IPの既存および新しいサブネットワークテクノロジーの両方を可能な限り最適化することは理にかなっています。
Optimizing a subnetwork for IP involves three complementary considerations:
IPのサブネットワークを最適化するには、3つの補完的な考慮事項が含まれます。
1. Providing functionality sufficient to carry IP.
1. IPを運ぶのに十分な機能を提供します。
2. Eliminating unnecessary functions that increase cost or complexity.
2. コストまたは複雑さを高める不必要な機能を排除します。
3. Choosing subnetwork parameters that maximize the performance of the Internet protocols.
3. インターネットプロトコルのパフォーマンスを最大化するサブネットワークパラメーターの選択。
Because IP is so simple, consideration 2 is more of an issue than consideration 1. That is to say, subnetwork designers make many more errors of commission than errors of omission. However, certain enhancements to Internet features, such as multicasting and quality-of-service, benefit significantly from support given by the underlying subnetworks beyond that necessary to carry "traditional" unicast, best-effort IP.
IPは非常に単純であるため、考慮事項2は考慮事項よりも問題です。つまり、サブネットワークの設計者は、省略の誤りよりも多くの手数料の誤りを犯します。ただし、マルチキャストやサービス品質などのインターネット機能の特定の強化は、「従来の」ユニキャスト、ベストエフォルトIPを運ぶために必要なものを超えて、基礎となるサブネットワークが提供するサポートから大幅に利益を得ています。
A major consideration in the efficient design of any layered communication network is the appropriate layer(s) in which to implement a given function. This issue was first addressed in the seminal paper, "End-to-End Arguments in System Design" [SRC81]. That paper argued that many functions can be implemented properly *only* on an end-to-end basis, i.e., at the highest protocol layers, outside the subnetwork. These functions include ensuring the reliable delivery of data and the use of cryptography to provide confidentiality and message integrity.
階層化された通信ネットワークの効率的な設計における主要な考慮事項は、特定の関数を実装する適切なレイヤーです。この問題は、「システム設計におけるエンドツーエンドの引数」[SRC81]の独創的な論文で最初に扱われました。その論文は、多くの関数をエンドツーエンドベースで、つまりサブネットワークの外側の最高のプロトコル層で適切に *のみ *のみ実装できると主張しました。これらの機能には、データの信頼できる配信の確保と暗号化の使用のための暗号化とメッセージの整合性が含まれます。
Such functions cannot be provided solely by the concatenation of hop-by-hop services; duplicating these functions at the lower protocol layers (i.e., within the subnetwork) can be needlessly redundant or even harmful to cost and performance.
このような機能は、ホップバイホップサービスの連結だけでは提供できません。これらの機能を下部プロトコル層（つまり、サブネットワーク内）で複製することは、コストとパフォーマンスに不必要に冗長または有害でさえあります。
However, partial duplication of functionality in a lower layer can *sometimes* be justified by performance, security, or availability considerations. Examples include link-layer retransmission to improve the performance of an unusually lossy channel, e.g., mobile radio, link-level encryption intended to thwart traffic analysis, and redundant transmission links to improve availability, increase throughput, or to guarantee performance for certain classes of traffic. Duplication of protocol functions should be done only with an understanding of system-level implications, including possible interactions with higher-layer mechanisms.
ただし、下層の機能の部分的な複製は、パフォーマンス、セキュリティ、または可用性の考慮事項によって *時々 *正当化される可能性があります。例には、リンク層の再送信が含まれます。例：モバイルラジオ、トラフィック分析を阻止するためのモバイルラジオ、リンクレベルの暗号化、および可用性を向上させるための冗長トランスミッションリンク、スループットの増加、または特定のクラスのパフォーマンスを保証するための冗長トランスミッションリンク渋滞。プロトコル関数の複製は、高層メカニズムとの相互作用の可能性を含む、システムレベルの意味を理解することでのみ行う必要があります。
The original architecture of the Internet was influenced by the end-to-end principle [SRC81], and has been, in our view, part of the reason for the Internet's success.
インターネットの元のアーキテクチャは、エンドツーエンドの原則[SRC81]の影響を受け、私たちの見解では、インターネットの成功の理由の一部でした。
The remainder of this document discusses the various subnetwork design issues that the authors consider relevant to efficient IP support.
このドキュメントの残りの部分では、著者が効率的なIPサポートに関連すると考えているさまざまなサブネットワークの設計上の問題について説明しています。
IPv4 packets (datagrams) vary in size, from 20 bytes (the size of the IPv4 header alone) to a maximum of 65535 bytes. Subnetworks need not support maximum-sized (64KB) IP packets, as IP provides a scheme that breaks packets that are too large for a given subnetwork into fragments that travel as independent IP packets and are reassembled at the destination. The maximum packet size supported by a subnetwork is known as its Maximum Transmission Unit (MTU).
IPv4パケット（データグラム）のサイズは、20バイト（IPv4ヘッダーのサイズだけ）から最大65535バイトまでさまざまです。IPは、特定のサブネットワークが大きすぎて独立したIPパケットとして移動し、目的地で再組み立てされているフラグメントに大きすぎるパケットを破壊するスキームを提供するため、最大サイズの（64kb）IPパケットをサポートする必要はありません。サブネットワークでサポートされている最大パケットサイズは、最大透過ユニット（MTU）として知られています。
Subnetworks may, but are not required to, indicate the length of each packet they carry. One example is Ethernet with the widely used DIX [DIX82] (not IEEE 802.3 [IEEE8023]) header, which lacks a length field to indicate the true data length when the packet is padded to a minimum of 60 bytes. This is not a problem for uncompressed IP because each IP packet carries its own length field.
Subnetworksは、携帯する各パケットの長さを示すことができますが、必要ではありません。1つの例は、広く使用されているDIX [DIX82]（IEEE 802.3 [IEEE8023]ではない）のヘッダーを備えたイーサネットです。これは、パケットが最低60バイトにパッドにされたときの真のデータ長を示す長さのフィールドを欠いています。各IPパケットには独自の長さフィールドがあるため、これは圧縮されていないIPの問題ではありません。
If optional header compression [RFC1144] [RFC2507] [RFC2508] [RFC3095] is used, however, it is required that the link framing indicate frame length because that is needed for the reconstruction of the original header.
オプションのヘッダー圧縮[RFC1144] [RFC2507] [RFC2508] [RFC3095]が使用されますが、元のヘッダーの再構成に必要なため、リンクフレーミングがフレーム長を示す必要があります。
In IP version 4 (the version now in widespread use), fragmentation can occur at either the sending host or in an intermediate router, and fragments can be further fragmented at subsequent routers if necessary.
IPバージョン4（現在は広く使用されているバージョン）では、送信ホストまたは中間ルーターで断片化が発生し、必要に応じて後続のルーターでフラグメントをさらに断片化できます。
In IP version 6 [RFC2460], fragmentation can occur only at the sending host; it cannot occur in a router (called "router fragmentation" in this document).
IPバージョン6 [RFC2460]では、送信ホストでのみ断片化が発生する可能性があります。ルーター（このドキュメントでは「ルーターフラグメンテーション」と呼ばれる）で発生することはできません。
Both IPv4 and IPv6 provide a "path MTU discovery" procedure [RFC1191] [RFC1435] [RFC1981] that allows the sending host to avoid fragmentation by discovering the minimum MTU along a given path and reduce its packet sizes accordingly. This procedure is optional in IPv4 and IPv6.
IPv4とIPv6の両方は、「パスMTU発見」手順[RFC1191] [RFC1435] [RFC1981]を提供します。この手順は、IPv4およびIPv6でオプションです。
Path MTU discovery is widely deployed, but it sometimes encounters problems. Some routers fail to generate the ICMP messages that convey path MTU information to the sender, and sometimes the ICMP messages are blocked by overly restrictive firewalls. The result can be a "Path MTU Black Hole" [RFC2923] [RFC1435].
Path MTU Discoveryは広く展開されていますが、問題に遭遇することがあります。一部のルーターは、パスMTU情報を送信者に伝えるICMPメッセージを生成できず、場合によってはICMPメッセージが過度に制限されたファイアウォールによってブロックされる場合があります。結果は、「パスMTUブラックホール」[RFC2923] [RFC1435]になります。
The Path MTU Discovery procedure, the persistence of path MTU black holes, and the deletion of router fragmentation in IPv6 reflect a consensus of the Internet technical community that router fragmentation is best avoided. This requires that subnetworks support MTUs that are "reasonably" large. All IPv4 end hosts are required to accept and reassemble IP packets of size 576 bytes [RFC791], but such a small value would clearly be inefficient. Because IPv6 omits fragmentation by routers, [RFC2460] specifies a larger minimum MTU of 1280 bytes. Any subnetwork with an internal packet payload smaller than 1280 bytes must implement a mechanism that performs fragmentation/reassembly of IP packets to/from subnetwork frames if it is to support IPv6.
PATH MTU発見手順、PATH MTUブラックホールの持続性、およびIPv6におけるルーターの断片化の削除は、ルーターの断片化が回避されるのが最善であるというインターネット技術コミュニティのコンセンサスを反映しています。これには、サブネットワークが「合理的に」大きいMTUをサポートする必要があります。すべてのIPv4エンドホストは、サイズ576バイト[RFC791]のIPパケットを受け入れて再組み立てる必要がありますが、このような小さな値は明らかに非効率的です。IPv6はルーターによる断片化を省略しているため、[RFC2460]は1280バイトのより大きな最小MTUを指定します。1280バイト未満の内部パケットペイロードを備えたサブネットワークは、IPv6をサポートする場合、サブネットワークフレームにIPパケットの断片化/再組み立てを実行するメカニズムを実装する必要があります。
If a subnetwork cannot directly support a "reasonable" MTU with native framing mechanisms, it should internally fragment. That is, it should transparently break IP packets into internal data elements and reassemble them at the other end of the subnetwork.
サブネットワークがネイティブフレーミングメカニズムを備えた「合理的な」MTUを直接サポートできない場合、内部的に断片化する必要があります。つまり、IPパケットを内部データ要素に透過的に分割し、サブネットワークの反対側で再組み立てする必要があります。
This leaves the question of what is a "reasonable" MTU. Ethernet (10 and 100 Mb/s) has an MTU of 1500 bytes, and because of the ubiquity of Ethernet few Internet paths currently have MTUs larger than this value. This severely limits the utility of larger MTUs provided by other subnetworks. Meanwhile, larger MTUs are increasingly desirable on high-speed subnetworks to reduce the per-packet processing overhead in host computers, and implementers are encouraged to provide them even though they may not be usable when Ethernet is also in the path.
これは、「合理的な」MTUとは何かの問題を残します。イーサネット（10および100 Mb/s）のMTUは1500バイトで、イーサネットの遍在のため、現在、この値よりもMTUが大きいインターネットパスはほとんどありません。これにより、他のサブネットワークが提供するより大きなMTUのユーティリティが大幅に制限されます。一方、ホストコンピューターのパケットごとの処理オーバーヘッドを削減するために、高速サブネットワークでは、より大きなMTUがますます望ましいものであり、イーサネットがパスにあるときに使用できない場合でも、実装者はそれらを提供することをお勧めします。
Various "tunneling" schemes, such as GRE [RFC2784] or IP Security in tunnel mode [RFC2406], treat IP as a subnetwork for IP. Since tunneling adds header overhead, it can trigger fragmentation, even when the same physical subnetworks (e.g., Ethernet) are used on both sides of the host performing IPsec encapsulation. Tunneling has made it more difficult to avoid router fragmentation and has increased the incidence of path MTU black holes [RFC2401] [RFC2923]. Larger subnetwork MTUs may help to alleviate this problem.
GRE [RFC2784]やトンネルモードのIPセキュリティ[RFC2406]などのさまざまな「トンネル」スキームは、IPをIPのサブネットワークとして扱います。トンネリングはヘッダーのオーバーヘッドを追加するため、同じ物理サブネットワーク（例えば、イーサネット）がIPSECカプセル化を実行するホストの両側で使用されている場合でも、断片化をトリガーできます。トンネリングにより、ルーターの断片化を回避することがより困難になり、経路MTUブラックホールの発生率が増加しました[RFC2401] [RFC2923]。より大きなサブネットワークMTUは、この問題を軽減するのに役立つ場合があります。
In slow networks, the largest possible packet may take a considerable amount of time to send. This is known as channelisation or serialisation delay. Total end-to-end interactive response time should not exceed the well-known human factors limit of 100 to 200 ms. This includes all sources of delay: electromagnetic propagation delay, queuing delay, serialisation delay, and the store-and-forward time, i.e., the time to transmit a packet at link speed.
遅いネットワークでは、可能な限り最大のパケットが送信にかなりの時間がかかる場合があります。これは、チャネル化またはシリアル化遅延として知られています。総エンドツーエンドのインタラクティブな応答時間は、よく知られている人的要因の制限100〜200ミリ秒を超えてはなりません。これには、すべての遅延源が含まれます。電磁伝播遅延、キューイングの遅延、シリアル化遅延、ストアアンドフォータイム、つまりリンク速度でパケットを送信する時間です。
At low link speeds, store-and-forward delays can dominate total end-to-end delay; these are in turn directly influenced by the maximum transmission unit (MTU) size. Even when an interactive packet is given a higher queuing priority, it may have to wait for a large bulk transfer packet to finish transmission. This worst-case wait can be set by an appropriate choice of MTU.
低リンク速度では、ストアアンドフォワードの遅延が総エンドツーエンド遅延を支配することができます。これらは、最大透過ユニット（MTU）サイズの影響を直接影響を受けます。インタラクティブなパケットがより高いキューイングの優先順位を与えられた場合でも、大量のバルク転送パケットが送信を完了するのを待たなければならない場合があります。この最悪の待機は、MTUの適切な選択によって設定できます。
For example, if the MTU is set to 1500 bytes, then an MTU-sized packet will take about 8 milliseconds to send on a T1 (1.536 Mb/s) link. But if the link speed is 19.2kb/s, then the transmission time becomes 625 ms -- well above our 100-200ms limit. A 256-byte MTU would lower this delay to a little over 100 ms. However, care should be taken not to lower the MTU excessively, as this will increase header overhead and trigger frequent router fragmentation (if Path MTU discovery is not in use). This is likely to be the case with multicast, where Path MTU discovery is ineffective.
たとえば、MTUが1500バイトに設定されている場合、MTUサイズのパケットは約8ミリ秒かかり、T1（1.536 Mb/s）リンクを送信します。ただし、リンク速度が19.2kb/sの場合、送信時間は625ミリ秒になります。これは、100〜200msの制限を大きく上回っています。256バイトのMTUは、この遅延を100ミリ秒以上に減らします。ただし、MTUを過度に下げないように注意する必要があります。これにより、ヘッダーのオーバーヘッドが増加し、頻繁なルーターの断片化がトリガーされるためです（Path MTU発見が使用されていない場合）。これは、Path MTUの発見が効果的でないマルチキャストの場合である可能性があります。
One way to limit delay for interactive traffic without imposing a small MTU is to give priority to this traffic and to preempt (abort) the transmission of a lower-priority packet when a higher priority packet arrives in the queue. However, the link resources used to send the aborted packet are lost, and overall throughput will decrease.
小さなMTUを課すことなくインタラクティブトラフィックの遅延を制限する1つの方法は、このトラフィックを優先し、より高い優先度パケットがキューに到着したときにより低優先度パケットの送信を先取りする（abort）することです。ただし、中止されたパケットの送信に使用されるリンクリソースは失われ、全体的なスループットが減少します。
Another way to limit delay is to implement a link-level multiplexing scheme that allows several packets to be in progress simultaneously, with transmission priority given to segments of higher-priority IP packets. For links using the Point-To-Point Protocol (PPP) [RFC1661], multi-class multilink [RFC2686] [RFC2687] [RFC2689] provides such a facility.
遅延を制限する別の方法は、より優先順位IPパケットのセグメントに送信の優先度が与えられ、複数のパケットを同時に進行させるリンクレベルの多重化スキームを実装することです。ポイントツーポイントプロトコル（PPP）[RFC1661]を使用したリンクの場合、マルチクラスマルチリンク[RFC2686] [RFC2687] [RFC2689]はそのような施設を提供します。
ATM (asynchronous transfer mode), where SNDUs are fragmented and interleaved across smaller 53-byte ATM cells, is another example of this technique. However, ATM is generally used on high-speed links where the store-and-forward delays are already minimal, and it introduces significant (~9%) increases in overhead due to the addition of 5-byte cell overhead to each 48-byte ATM cell.
SNDUが断片化され、より小さな53バイトのATMセル全体にインターリーブされているATM（非同期伝達モード）は、この手法のもう1つの例です。ただし、ATMは一般に、ストアアンドフォワードの遅延がすでに最小限である高速リンクで使用され、各48バイトに5バイトのセルオーバーヘッドが追加されているため、オーバーヘッドに大幅な（〜9％）増加します。ATMセル。
A third example is the Data-Over-Cable Service Interface Specification (DOCSIS) with typical upstream bandwidths of 2.56 Mb/s or 5.12 Mb/s. To reduce the impact of a 1500-byte MTU in DOCSIS 1.0 [DOCSIS1], a data link layer fragmentation mechanism is specified in DOCSIS 1.1 [DOCSIS2]. To accommodate the installed base, DOCSIS 1.1 must be backward compatible with DOCSIS 1.0 cable modems, which generally do not support fragmentation. Under the co-existence of DOCSIS 1.0 and DOCSIS 1.1, the unfragmented large data packets from DOCSIS 1.0 cable modems may affect the quality of service for voice packets from DOCSIS 1.1 cable modems. In this case, it has been shown in [DOCSIS3] that the use of bandwidth allocation algorithms can mitigate this effect.
3番目の例は、2.56 MB/sまたは5.12 Mb/sの典型的な上流帯域幅を持つデータオーバーケーブルサービスインターフェイス仕様（DOCSIS）です。DOCSIS 1.0 [DOCSIS1]における1500バイトのMTUの影響を減らすために、DOCSIS 1.1 [DOCSIS2]でデータリンクレイヤーフラグメンテーションメカニズムが指定されています。インストールされたベースに対応するには、DOCSIS 1.1は、一般に断片化をサポートしないDOCSIS 1.0ケーブルモデムと後方互換性がなければなりません。DOCSIS 1.0とDOCSIS 1.1の共存の下で、DOCSIS 1.0ケーブルモデムからの不断の大規模なデータパケットは、DOCSIS 1.1ケーブルモデムからの音声パケットのサービス品質に影響を与える可能性があります。この場合、帯域幅割り当てアルゴリズムの使用がこの効果を軽減できることが[docsis3]で示されています。
To summarize, there is a fundamental tradeoff between efficiency and latency in the design of a subnetwork, and the designer should keep this tradeoff in mind.
要約すると、サブネットワークの設計には効率性とレイテンシの間に基本的なトレードオフがあり、デザイナーはこのトレードオフを念頭に置いておく必要があります。
IP requires that subnetworks mark the beginning and end of each variable-length, asynchronous IP packet. Some examples of links and subnetworks that do not provide this as an intrinsic feature include:
IPでは、サブネットワークが各変数長の非同期IPパケットの開始と終了をマークする必要があります。これを本質的な機能として提供しないリンクとサブネットワークのいくつかの例は次のとおりです。
1. leased lines carrying a synchronous bit stream;
1. 同期ビットストリームを運ぶリースライン。
2. ISDN B-channels carrying a synchronous octet stream;
2. 同期オクテットストリームを運ぶISDN Bチャネル。
3. dialup telephone modems carrying an asynchronous octet stream;
3. 非同期オクテットストリームを運ぶ電話モデムをダイヤルアップします。
and
そしてと及びアンド並びに且つ兼又共それですると亦だからそれからはたまた
4. Asynchronous Transfer Mode (ATM) networks carrying an asynchronous stream of fixed-sized "cells".
4. 固定サイズの「セル」の非同期ストリームを運ぶ非同期転送モード（ATM）ネットワーク。
The Internet community has defined packet framing methods for all these subnetworks. The Point-To-Point Protocol (PPP) [RFC1661], which uses a variant of HDLC, is applicable to bit synchronous, octet-synchronous, and octet asynchronous links (i.e., examples 1-3 above). PPP is one preferred framing method for IP, since a large number of systems interoperate with PPP. ATM has its own framing methods, described in [RFC2684] [RFC2364].
インターネットコミュニティは、これらすべてのサブネットワークのパケットフレーミング方法を定義しています。HDLCのバリアントを使用するポイントツーポイントプロトコル（PPP）[RFC1661]は、ビット同期、オクテット同期、およびオクテットの非同期リンクに適用できます（つまり、上記の例1-3）。多数のシステムがPPPと相互操作するため、PPPはIPの優先フレーミング方法の1つです。ATMには、[RFC2684] [RFC2364]に記載されている独自のフレーミング方法があります。
At high speeds, a subnetwork should provide a framed interface capable of carrying asynchronous, variable-length IP datagrams. The maximum packet size supported by this interface is discussed above in the MTU/Fragmentation section. The subnetwork may implement this facility in any convenient manner.
高速では、サブネットワークは、非同期の可変長さのIPデータグラムを運ぶことができるフレーム付きインターフェイスを提供する必要があります。このインターフェイスでサポートされている最大パケットサイズについては、上記のMTU/断片化セクションで説明します。サブネットワークは、この施設を便利な方法で実装できます。
IP packet boundaries need not coincide with any framing or synchronization mechanisms internal to the subnetwork. When the subnetwork implements variable sized data units, the most straightforward approach is to place exactly one IP packet into each subnetwork data unit (SNDU), and to rely on the subnetwork's existing ability to delimit SNDUs to also delimit IP packets. A good example is Ethernet. However, some subnetworks have SNDUs of one or more fixed sizes, as dictated by switching, forward error correction and/or interleaving considerations. Examples of such subnetworks include ATM, with a single cell payload size of 48 octets plus a 5- octet header, and IS-95 digital cellular, with two "rate sets" of four fixed frame sizes each that may be selected on 20 millisecond boundaries.
IPパケットの境界は、サブネットワークの内部のフレーミングまたは同期メカニズムと一致する必要はありません。サブネットワークが可変サイズのデータユニットを実装する場合、最も簡単なアプローチは、各サブネットワークデータユニット（SNDU）に正確に1つのIPパケットを配置し、サブネットワークの既存の機能に依存してSNDUを設定してIPパケットを区切ることです。良い例はイーサネットです。ただし、一部のサブネットワークには、切り替え、前方エラーの修正、および/またはインターリーブの考慮事項によって指示されるように、1つ以上の固定サイズのSNDUがあります。このようなサブネットワークの例には、ATMが含まれます。ATMには、48オクテットと5-オクテットヘッダーの単一セルペイロードサイズがあり、IS-95デジタルセルラーがあり、20ミリ秒の境界で選択できる4つの固定フレームサイズの2つの「レートセット」があります。。
Because IP packets are of variable length, they may not necessarily fit into an integer multiple of fixed-sized SNDUs. An "adaptation layer" is needed to convert IP packets into SNDUs while marking the boundary between each IP packet in some manner.
IPパケットはさまざまな長さであるため、固定サイズのSNDUの整数倍に必ずしも収まるとは限りません。IPパケットをSNDUに変換しながら、各IPパケット間の境界を何らかの方法でマークするには、「適応レイヤー」が必要です。
There are several approaches to this problem. The first is to encode each IP packet into one or more SNDUs with no SNDU containing pieces of more than one IP packet, and to pad out the last SNDU of the packet as needed. Bits in a control header added to each SNDU indicate where the data segment belongs in the IP packet. If the subnetwork provides in-order, at-most-once delivery, the header can be as simple as a pair of bits indicating whether the SNDU is the first and/or the last in the IP packet. Alternatively, for subnetworks that do not reorder the fragments of an SNDU, only the last SNDU of the packet could be marked, as this would implicitly indicate the next SNDU as the first in a new IP packet. The AAL5 (ATM Adaptation Layer 5) scheme used with ATM is an example of this approach, though it adds other features, including a payload length field and a payload CRC.
この問題にはいくつかのアプローチがあります。1つ目は、各IPパケットを1つ以上のSNDUにエンコードして、複数のIPパケットを含むSNDUが含まれていない場合、必要に応じてパケットの最後のSNDUをパッドアウトすることです。各SNDUに追加されたコントロールヘッダー内のビットは、データセグメントがIPパケット内のどこに属しているかを示します。サブネットワークが注文の最新配信を提供する場合、ヘッダーは、SNDUがIPパケットの最初のおよび/または最後であるかどうかを示すビットのペアと同じくらい簡単にすることができます。あるいは、SNDUのフラグメントを再注文しないサブネットワークの場合、パケットの最後のSNDUのみをマークすることができます。これは、新しいIPパケットの最初のSNDUとして暗黙的に示されるためです。ATMで使用されるAAL5（ATM適応レイヤー5）スキームは、このアプローチの例ですが、ペイロード長フィールドやペイロードCRCなど、他の機能を追加します。
In AAL5, the ATM User-User Indication, which is encoded in the Payload Type field of an ATM cell, indicates the last cell of a packet. The packet trailer is located at the end of the SNDU and contains the packet length and a CRC.
AAL5では、ATMセルのペイロードタイプフィールドにエンコードされたATMユーザーユーザーの表示が、パケットの最後のセルを示します。パケットトレーラーはSNDUの端にあり、パケットの長さとCRCが含まれています。
Another framing technique is to insert per-segment overhead to indicate the presence of a segment option. When present, the option carries a pointer to the end of the packet. This differs from AAL5 in that it permits another packet to follow within the same segment. MPEG-2 Transport Streams [EN301192] [ISO13818] support this style of fragmentation, and may either use padding (limiting each MPEG transport stream packet to carry only part of one IP packet), or allow a second IP packet to start in the same Transport Stream packet (no padding).
別のフレーミング手法は、セグメントごとのオーバーヘッドを挿入して、セグメントオプションの存在を示すことです。存在する場合、オプションはパケットの最後までポインターを持ちます。これは、別のパケットが同じセグメント内で従うことを許可するという点で、AAL5とは異なります。MPEG-2トランスポートストリーム[EN301192] [ISO13818]はこのスタイルの断片化をサポートし、パディングを使用して（各MPEGトランスポートストリームパケットを制限して1つのIPパケットの一部のみを運ぶ）、または2番目のIPパケットが同じで開始できるようにすることができます。輸送ストリームパケット（パディングなし）。
A third approach is to insert a special flag sequence into the data stream between each IP packet, and to pack the resulting data stream into SNDUs without regard to SNDU boundaries. This may have implications when frames are lost. The flag sequence can also pad unused space at the end of an SNDU. If the special flag appears in the user data, it is escaped to an alternate sequence (usually larger than a flag) to avoid being misinterpreted as a flag. The HDLC-based framing schemes used in PPP are all examples of this approach.
3番目のアプローチは、各IPパケット間のデータストリームに特別なフラグシーケンスを挿入し、SNDUの境界に関係なく、結果のデータストリームをSNDUに詰めることです。これは、フレームが失われたときに影響を与える可能性があります。フラグシーケンスは、SNDUの終わりに未使用のスペースを埋めることもできます。ユーザーデータに特別なフラグが表示される場合、フラグと誤解されないように、代替シーケンス（通常はフラグよりも大きい）に逃げられます。PPPで使用されるHDLCベースのフレーミングスキームはすべて、このアプローチの例です。
All three adaptation schemes introduce overhead; how much depends on the distribution of IP packet sizes, the size(s) of the SNDUs, and in the HDLC-like approaches, the content of the IP packet (since flag-like sequences occurring in the packet must be escaped, which expands them). The designer must also weigh implementation complexity and performance in the choice and design of an adaptation layer.
3つの適応スキームはすべて、頭上を導入します。どれだけの量は、IPパケットサイズの分布、SNDUのサイズ、およびHDLCのようなアプローチに依存します。IPパケットの内容（パケットで発生するフラグのようなシーケンスを逃がす必要があります。彼ら）。設計者は、適応層の選択と設計における実装の複雑さとパフォーマンスを比較検討する必要があります。
IP has no notion of a "connection"; it is a purely connectionless protocol. When a connection is required by an application, it is usually provided by TCP [RFC793], the Transmission Control Protocol, running atop IP on an end-to-end basis.
IPには「接続」の概念はありません。それは純粋にコネクションレスプロトコルです。アプリケーションで接続が必要な場合、通常、TCP [RFC793]、トランスミッションコントロールプロトコルで提供され、IPの上部でエンドツーエンドベースで実行されます。
Connection-oriented subnetworks can be (and are widely) used to carry IP, but often with considerable complexity. Subnetworks consisting of few nodes can simply open a permanent connection between each pair of nodes. This is frequently done with ATM. However, the number of connections increases as the square of the number of nodes, so this is clearly impractical for large subnetworks. A "shim" layer between IP and the subnetwork is therefore required to manage connections. This is one of the most common functions of a Subnetwork Dependent Convergence Function (SNDCF) sublayer between IP and a subnetwork.
接続指向のサブネットワークは、IPを運ぶために使用される（そして広く使用されています）が、多くの場合、かなり複雑になります。少数のノードで構成されるサブネットワークは、各ノードのペア間の永続的な接続を単純に開くことができます。これは頻繁にATMで行われます。ただし、接続の数はノードの数の平方として増加するため、これは大規模なサブネットワークでは明らかに非現実的です。したがって、IPとサブネットワークの間の「シム」レイヤーは、接続を管理するために必要です。これは、IPとサブネットワークの間のサブネットワーク依存性収束関数（SNDCF）サブレイヤーの最も一般的な関数の1つです。
SNDCFs typically open subnetwork connections as needed when an IP packet is queued for transmission and close them after an idle timeout. There is no relation between subnetwork connections and any connections that may exist at higher layers (e.g., TCP).
SNDCFは、通常、IPパケットが送信用にキューにキューになったときに必要に応じてサブネットワーク接続を開き、アイドルタイムアウト後に閉じます。サブネットワーク接続と、高層（TCPなど）で存在する可能性のある接続との間に関係はありません。
Because Internet traffic is typically bursty and transaction-oriented, it is often difficult to pick an optimal idle timeout. If the timeout is too short, subnetwork connections are opened and closed rapidly, possibly over-stressing the subnetwork connection management system (especially if it was designed for voice traffic call holding times). If the timeout is too long, subnetwork connections are idle much of the time, wasting any resources dedicated to them by the subnetwork.
インターネットトラフィックは通常バースト的でトランザクション指向であるため、最適なアイドルタイムアウトを選択することはしばしば困難です。タイムアウトが短すぎる場合、サブネットワーク接続が開閉され、急速に閉じられ、サブネットワーク接続管理システムのストレスが過度にストレスをかけている可能性があります（特に音声トラフィックコールホールド時間用に設計された場合）。タイムアウトが長すぎる場合、サブネットワークの接続はほとんどの場合アイドル状態であり、サブネットワークによってそれらに特化したリソースを無駄にします。
Purely connectionless subnets (such as Ethernet), which have no state and dynamically share resources, are optimal for supporting best-effort IP, which is stateless and dynamically shares resources. Connection-oriented packet networks (such as ATM and Frame Relay), which have state and dynamically share resources, are less optimal, since best-effort IP does not benefit from the overhead of creating and maintaining state. Connection-oriented circuit-switched networks (including the PSTN and ISDN) have state and statically allocate resources for a call, and thus require state creation and maintenance overhead, but do not benefit from the efficiencies of statistical multiplexing sharing of capacity inherent in IP.
状態がなく、動的にリソースを共有する純粋にコネクションレスサブネット（イーサネットなど）は、ステートレスで動的にリソースを共有するベストエフォルトIPをサポートするのに最適です。ベストエフォルトIPは状態の作成と維持のオーバーヘッドから利益を得ないため、状態および動的共有リソースを持つ接続指向のパケットネットワーク（ATMやフレームリレーなど）は最適ではありません。接続指向の回路スイッチネットワーク（PSTNおよびISDNを含む）には状態があり、コールのリソースを静的に割り当てるため、状態の作成とメンテナンスのオーバーヘッドが必要ですが、IPに固有の容量の統計的多重化共有の効率から利益を得ません。
In any event, if an SNDCF that opens and closes subnet connections is used to support IP, care should be taken to make sure that connection processing in the subnet can keep up with relatively short holding times.
いずれにせよ、サブネット接続を開閉して閉じるSNDCFがIPをサポートするために使用される場合、サブネットの接続処理が比較的短い保持時間に追いつくことができるように注意する必要があります。
Subnetworks fall into two categories: point-to-point and shared. A point-to-point subnet has exactly two endpoint components (hosts or routers); a shared link has more than two endpoint components, using either an inherently broadcast medium (e.g., Ethernet, radio) or a switching layer hidden from the network layer (e.g., switched Ethernet, Myrinet [MYR95], ATM). Switched subnetworks handle broadcast by copying broadcast packets, providing each interface that supports one, or more, systems (hosts or routers) with a copy of each packet.
サブネットワークは、ポイントツーポイントと共有の2つのカテゴリに分類されます。ポイントツーポイントサブネットには、正確に2つのエンドポイントコンポーネント（ホストまたはルーター）があります。共有リンクには、本質的にブロードキャスト媒体（イーサネット、ラジオなど）またはネットワークレイヤーから隠されたスイッチングレイヤー（たとえば、Switched Ethernet、MyRInet [MyR95]、ATM）を使用して、2つ以上のエンドポイントコンポーネントがあります。Switched SubnetWorksは、ブロードキャストパケットをコピーしてブロードキャストを処理し、各パケットのコピーを1つ以上のシステム（ホストまたはルーター）をサポートする各インターフェイスを提供します。
Several Internet protocols for IPv4 make use of broadcast capabilities, including link-layer address lookup (ARP), auto-configuration (RARP, BOOTP, DHCP), and routing (RIP).
IPv4用のいくつかのインターネットプロトコルは、リンクレイヤーアドレスルックアップ（ARP）、自動コンフィグレーザー（RARP、BOOTP、DHCP）、ルーティング（RIP）などのブロードキャスト機能を使用しています。
A lack of broadcast capability can impede the performance of these protocols, or render them inoperable (e.g., DHCP). ARP-like link address lookup can be provided by a centralized database, but at the expense of potentially higher response latency and the need for nodes to have explicit knowledge of the ARP server address. Shared links should support native, link-layer subnet broadcast.
ブロードキャスト機能の欠如は、これらのプロトコルのパフォーマンスを妨げたり、動作不能にしたりする可能性があります（DHCPなど）。ARPのようなリンクアドレスルックアップは、集中データベースによって提供できますが、応答の遅延が潜在的に高いことと、ARPサーバーアドレスの明示的な知識を持つノードの必要性を犠牲にします。共有リンクは、ネイティブのリンク層サブネットブロードキャストをサポートする必要があります。
A corresponding set of IPv6 protocols uses multicasting (see next section) instead of broadcasting to provide similar functions with improved scaling in large networks.
IPv6プロトコルの対応するセットは、ブロードキャストではなくマルチリキャスト（次のセクションを参照）を使用して、大規模なネットワークでのスケーリングを改善した同様の関数を提供します。
The Internet model includes "multicasting", where IP packets are sent to all the members of a multicast group [RFC1112] [RFC3376] [RFC2710]. Multicast is an option in IPv4, but a standard feature of IPv6. IPv4 multicast is currently used by multimedia, teleconferencing, gaming, and file distribution (web, peer-to-peer sharing) applications, as well as by some key network and host protocols (e.g., RIPv2, OSPF, NTP). IPv6 additionally relies on multicast for network configuration (DHCP-like autoconfiguration) and link-layer address discovery [RFC2461] (replacing ARP). In the case of IPv6, this can allow autoconfiguration and address discovery to span across routers, whereas the IPv4 broadcast-based services cannot without ad-hoc router support [RFC1812].
インターネットモデルには「マルチキャスト」が含まれており、IPパケットはマルチキャストグループ[RFC1112] [RFC3376] [RFC2710]のすべてのメンバーに送信されます。マルチキャストはIPv4のオプションですが、IPv6の標準機能です。IPv4マルチキャストは現在、マルチメディア、テレコンファレンス、ゲーム、ファイルディストリビューション（Web、ピアツーピア共有）アプリケーション、およびいくつかの主要なネットワークおよびホストプロトコル（RIPv2、OSPF、NTPなど）によって使用されています。IPv6は、さらに、ネットワーク構成のマルチキャスト（DHCPのようなオートコンフィグレーション）およびリンク層アドレスの発見[RFC2461]（ARPの交換）に依存しています。IPv6の場合、これによりオートコンチュレーションと対処された発見がルーターを横切ることができますが、IPv4ブロードキャストベースのサービスはアドホックルーターサポートなしではできません[RFC1812]。
Multicast-enabled IP routers organize each multicast group into a spanning tree, and route multicast packets by making copies of each multicast packet and forwarding the copies to each output interface that includes at least one downstream member of the multicast group.
マルチキャスト対応のIPルーターは、各マルチキャストグループをスパニングツリーに整理し、各マルチキャストパケットのコピーを作成し、マルチキャストグループの少なくとも1つのダウンストリームメンバーを含む各出力インターフェイスにコピーを転送します。
Multicasting is considerably more efficient when a subnetwork explicitly supports it. For example, a router relaying a multicast packet onto an Ethernet segment need send only one copy of the packet, no matter how many members of the multicast group are connected to the segment. Without native multicast support, routers and switches on shared links would need to use broadcast with software filters, such that every multicast packet sent incurs software overhead for every node on the subnetwork, even if a node is not a member of the multicast group. Alternately, the router would transmit a separate copy to every member of the multicast group on the segment, as is done on multicast-incapable switched subnets.
サブネットワークが明示的にサポートする場合、マルチキャストはかなり効率的です。たとえば、マルチキャストパケットをイーサネットセグメントにリレーするルーターは、マルチキャストグループのメンバーがセグメントに接続されている場合に関係なく、パケットのコピーを1つだけ送信する必要があります。ネイティブのマルチキャストサポートがなければ、共有リンクのルーターとスイッチはソフトウェアフィルターでブロードキャストを使用する必要があります。そのため、ノードがマルチキャストグループのメンバーではない場合でも、サブネットワーク上のすべてのノードにソフトウェアオーバーヘッドを送信するすべてのマルチキャストパケットが送信されます。あるいは、ルーターは、マルチキャストに入れられないスイッチ付きサブネットで行われるように、セグメント上のマルチキャストグループのすべてのメンバーに個別のコピーを送信します。
Subnetworks using shared channels (e.g., radio LANs, Ethernets) are especially suitable for native multicasting, and their designers should make every effort to support it. This involves designating a section of the subnetwork's own address space for multicasting. On these networks, multicast is basically broadcast on the medium, with Layer-2 receiver filters.
共有チャネル（ラジオLAN、イーサネットなど）を使用したサブネットワークは、ネイティブマルチキャストに特に適しており、デザイナーはそれをサポートするためにあらゆる努力をする必要があります。これには、マルチキャスト用のサブネットワーク独自のアドレススペースのセクションを指定することが含まれます。これらのネットワークでは、マルチキャストは基本的にメディアで放送され、レイヤー2レシーバーフィルターがあります。
Subnet interfaces also need to be designed to accept packets addressed to some number of multicast addresses, in addition to the unicast packets specifically addressed to them. The number of multicast addresses that needs to be supported by a host depends on the requirements of the associated host; at least several dozen will meet most current needs.
また、サブネットインターフェイスは、特別にアドレス指定されたユニキャストパケットに加えて、いくつかのマルチキャストアドレスにアドレス指定されたパケットを受け入れるように設計する必要があります。ホストがサポートする必要があるマルチキャストアドレスの数は、関連するホストの要件によって異なります。少なくとも数十人が現在のほとんどのニーズを満たします。
On low-speed networks, the multicast address recognition function may be readily implemented in host software, but on high-speed networks, it should be implemented in subnetwork hardware. This hardware need not be complete; for example, many Ethernet interfaces implement a "hashing" function where the IP layer receives all of the multicast (and unicast) traffic to which the associated host subscribes, plus some small fraction of multicast traffic to which the host does not subscribe. Host/router software then has to discard the unwanted packets that pass the Layer-2 multicast address filter [RFC1112].
低速ネットワークでは、マルチキャストアドレス認識関数はホストソフトウェアに容易に実装される場合がありますが、高速ネットワークでは、サブネットワークハードウェアに実装する必要があります。このハードウェアを完了する必要はありません。たとえば、多くのイーサネットインターフェイスは、IPレイヤーが関連するホストがサブスクライブするすべてのマルチキャスト（およびユニキャスト）トラフィックを受信する「ハッシュ」関数を実装し、さらにホストが購読していないマルチキャストトラフィックのほんの一部を実装します。ホスト/ルーターソフトウェアは、レイヤー2マルチキャストアドレスフィルター[RFC1112]を渡す不要なパケットを破棄する必要があります。
There does not need to be a one-to-one mapping between a Layer-2 multicast address and an IP multicast address. An address overlap may significantly degrade the filtering capability of a receiver's hardware multicast address filter. A subnetwork supporting only broadcast should use this service for multicast and must rely on software filtering.
Layer-2マルチキャストアドレスとIPマルチキャストアドレスの間に1対1のマッピングをする必要はありません。アドレスのオーバーラップは、受信機のハードウェアマルチキャストアドレスフィルターのフィルタリング機能を大幅に分解する場合があります。ブロードキャストのみをサポートするサブネットワークは、このサービスをマルチキャストに使用し、ソフトウェアフィルタリングに依存する必要があります。
Switched subnetworks must also provide a mechanism for copying multicast packets to ensure the packets reach at least all members of a multicast group. One option is to "flood" multicast packets in the same manner as broadcast. This can lead to unnecessary transmissions on some subnetwork links (notably non-multicast-aware Ethernet switches). Some subnetworks therefore allow multicast filter tables to control which links receive packets belonging to a specific group. To configure this automatically requires access to Layer-3 group membership information (e.g., IGMP [RFC3376], or MLD [RFC2710]). Various implementation options currently exist to provide a subnet node with a list of mappings of multicast addresses to ports/interfaces. These employ a range of approaches, including signaling from end hosts (e.g., IEEE 802 GARP/GMRP [802.1p]), signaling from switches (e.g., CGMP [CGMP] and RGMP [RFC3488]), interception and proxy of IP group membership packets (e.g., IGMP/MLD Proxy [MAGMA-PROXY]), and enabling Layer-2 devices to snoop/inspect/peek into forwarded Layer-3 protocol headers (e.g., IGMP, MLD, PIM) so that they may infer Layer-3 multicast group membership [MAGMA-SNOOP]. These approaches differ in their complexity, flexibility, and ability to support new protocols.
スイッチされたサブネットワークは、マルチキャストパケットをコピーするためのメカニズムを提供して、少なくともマルチキャストグループのすべてのメンバーにパケットに到達するようにする必要があります。1つのオプションは、ブロードキャストと同じ方法でマルチキャストパケットを「洪水」することです。これにより、いくつかのサブネットワークリンク（特にマルチカストに対応していないイーサネットスイッチ）に不必要な送信につながる可能性があります。したがって、一部のサブネットワークでは、マルチキャストフィルターテーブルが特定のグループに属するパケットを受信するリンクを制御できます。これを自動的に構成するには、レイヤー-3グループメンバーシップ情報（例：IGMP [RFC3376]、またはMLD [RFC2710]）へのアクセスが必要です。現在、さまざまな実装オプションが存在し、サブネットノードにポート/インターフェイスへのマルチキャストアドレスのマッピングのリストを提供しています。これらは、エンドホストからのシグナリング（IEEE 802 GARP/GMRP [802.1p]）、スイッチからのシグナル（例：CGMP [CGMP]およびRGMP [RFC3488]）、IPグループメンバーシップのインターセプトおよびプロキシなど、さまざまなアプローチを採用しています。パケット（例：IGMP/MLDプロキシ[Magma-Proxy]）、およびレイヤー-2デバイスが転送されたレイヤー-3プロトコルヘッダー（例えば、IGMP、MLD、PIM）をスヌープ/検査/覗き込んで、レイヤーを推測できるようにすることができます。3マルチキャストグループメンバーシップ[Magma-Snoop]。これらのアプローチは、複雑さ、柔軟性、および新しいプロトコルをサポートする能力が異なります。
Some subnets allow a number of subnet nodes to share a channel efficiently by assigning transmission opportunities dynamically. Transmission opportunities are requested by a subnet node when it has packets to send. The subnet schedules and grants transmission opportunities sufficient to allow the transmitting subnet node to send one or more packets (or packet fragments). We call these subnets Bandwidth on Demand (BoD) subnets. Examples of BoD subnets include Demand Assignment Multiple Access (DAMA) satellite and terrestrial wireless networks, IEEE 802.11 point coordination function (PCF) mode, and DOCSIS. A connection-oriented network (such as the PSTN, ATM or Frame Relay) reserves resources on a much longer timescale, and is therefore not a BoD subnet in our taxonomy.
一部のサブネットでは、多数のサブネットノードを使用して、送信機会を動的に割り当てることにより、チャネルを効率的に共有できます。送信パケットがある場合、サブネットノードが送信することが要求されます。サブネットは、送信サブネットノードが1つ以上のパケット（またはパケットフラグメント）を送信できるようにするのに十分な送信機会をスケジュールおよび付与します。これらのサブネット帯域幅をオンデマンド（BOD）サブネットと呼びます。BODサブネットの例には、需要割り当てマルチアクセス（DAMA）衛星および地上ワイヤレスネットワーク、IEEE 802.11ポイント調整関数（PCF）モード、およびDOCSISが含まれます。接続指向のネットワーク（PSTN、ATM、またはフレームリレーなど）は、リソースをはるかに長いタイムスケールで予約するため、分類法のBODサブネットではありません。
The design parameters for BoD are similar to those in connection-oriented subnetworks, although the implementations may vary significantly. In BoD, the user typically requests access to the shared channel for some duration. Access may be allocated for a period of time at a specific rate, for a certain number of packets, or until the user releases the channel. Access may be coordinated through a central management entity or with a distributed algorithm amongst the users. Examples of the resource that may be shared include a terrestrial wireless hop, an upstream channel in a cable television system, a satellite uplink, and an end-to-end satellite channel.
BODの設計パラメーターは、接続指向のサブネットワークの設計パラメーターと似ていますが、実装は大幅に異なる場合があります。BODでは、ユーザーは通常、ある期間共有チャネルへのアクセスを要求します。アクセスは、特定の数のパケットに対して、またはユーザーがチャンネルをリリースするまで、特定のレートで一定期間割り当てることができます。アクセスは、中央管理エンティティを通じて、またはユーザーの間で分散アルゴリズムを使用して調整できます。共有される可能性のあるリソースの例には、陸生ワイヤレスホップ、ケーブルテレビシステムの上流チャネル、衛星アップリンク、エンドツーエンドの衛星チャネルなどがあります。
Long-delay BoD subnets pose problems similar to connection-oriented subnets in anticipating traffic. While connection-oriented subnets hold idle channels open expecting new data to arrive, BoD subnets request channel access based on buffer occupancy (or expected buffer occupancy) on the sending port. Poor performance will likely result if the sender does not anticipate additional traffic arriving at that port during the time it takes to grant a transmission request. It is recommended that the algorithm have the capability to extend a hold on the channel for data that has arrived after the original request was generated (this may be done by piggybacking new requests on user data).
Long-Delay BODサブネットは、トラフィックを予測する上で接続指向のサブネットと同様の問題を引き起こします。接続指向のサブネットはアイドルチャネルを開いて新しいデータが到着することを期待していますが、BODサブネットは送信ポートのバッファー占有率（または予想バッファー占有率）に基づいてチャネルアクセスを要求します。送信者が、送信リクエストを付与するのにかかる間にそのポートに到着する追加のトラフィックを予想しない場合、パフォーマンスが低下する可能性があります。アルゴリズムには、元のリクエストが生成された後に到着したデータのチャネルのホールドを拡張する機能を備えていることをお勧めします（これは、ユーザーデータの新しいリクエストをピギーバックすることによって行われる場合があります）。
There is a wide variety of BoD protocols available. However, there has been relatively little comprehensive research on the interactions between BoD mechanisms and Internet protocol performance. Research on some specific mechanisms is available (e.g., [AR02]). One item that has been studied is TCP's retransmission timer [KY02]. BoD systems can cause spurious timeouts when adjusting from a relatively high data rate, to a relatively low data rate. In this case, TCP's transmitted data takes longer to get through the network than predicted by the TCP sender's computed retransmission timeout. Therefore, the TCP sender is prone to resending a segment prematurely.
さまざまなBODプロトコルが利用可能です。ただし、BODメカニズムとインターネットプロトコルのパフォーマンスとの相互作用に関する包括的な研究は比較的ほとんどありませんでした。いくつかの特定のメカニズムに関する研究が利用可能です（例：[AR02]）。研究されている項目の1つは、TCPの再送信タイマー[KY02]です。BODシステムは、比較的高いデータレートから比較的低いデータレートに調整するときに、スプリアスタイムアウトを引き起こす可能性があります。この場合、TCPの送信データは、TCP Senderの計算された再送信タイムアウトによって予測されるよりも、ネットワークを通過するのに時間がかかります。したがって、TCP送信者は、セグメントを早期的に復活させる傾向があります。
In the Internet architecture, the ultimate responsibility for error recovery is at the end points [SRC81]. The Internet may occasionally drop, corrupt, duplicate, or reorder packets, and the transport protocol (e.g., TCP) or application (e.g., if UDP is used as the transport protocol) must recover from these errors on an end-to-end basis [RFC3155]. Error recovery in the subnetwork is therefore justifiable only to the extent that it can enhance overall performance. It is important to recognize that a subnetwork can go too far in attempting to provide error recovery services in the Internet environment. Subnet reliability should be "lightweight", i.e., it only has to be "good enough", *not* perfect.
インターネットアーキテクチャでは、エラー回復の最終的な責任はエンドポイントにあります[SRC81]。インターネットは、パケットを落としたり、破損したり、複製したり、パケットを再注文したりすることがあり、トランスポートプロトコル（TCPなど）またはアプリケーション（UDPが輸送プロトコルとして使用される場合）がエンドツーエンドベースでこれらのエラーから回復する必要があります。[RFC3155]。したがって、サブネットワークのエラー回復は、全体的なパフォーマンスを向上させる範囲でのみ正当化できます。サブネットワークは、インターネット環境でエラー回復サービスを提供しようとする際に行き過ぎていることを認識することが重要です。サブネットの信頼性は「軽量」でなければなりません。つまり、「十分に良い」だけでなく、完璧ではありません。
In this section, we discuss how to analyze characteristics of a subnetwork to determine what is "good enough". The discussion below focuses on TCP, which is the most widely-used transport protocol in the Internet. It is widely believed (and is a stated goal within the IETF) that non-TCP transport protocols should attempt to be "TCP-friendly" and have many of the same performance characteristics. Thus, the discussion below should be applicable, even to portions of the Internet where TCP may not be the predominant protocol.
このセクションでは、サブネットワークの特性を分析して、「十分に良い」ものを決定する方法について説明します。以下の議論は、インターネットで最も広く使用されている輸送プロトコルであるTCPに焦点を当てています。非TCP輸送プロトコルは「TCPに優しい」ことを試み、同じパフォーマンス特性の多くを持っているべきであると広く信じられている（そして、IETF内の目標である）。したがって、TCPが支配的なプロトコルではないインターネットの一部にも、以下の議論が適用されるべきです。
Error recovery involves the generation and transmission of redundant information computed from user data. Depending on how much redundant information is sent and how it is generated, the receiver can use it to reliably detect transmission errors, correct up to some maximum number of transmission errors, or both. The general approach is known as Error Control Coding, or ECC.
エラー回復には、ユーザーデータから計算された冗長な情報の生成と送信が含まれます。送信される冗長な情報の量と生成方法に応じて、受信機はそれを使用して、伝送エラーを確実に検出したり、最大数の伝送エラーを修正したり、その両方を修正します。一般的なアプローチは、エラー制御コーディング、またはECCとして知られています。
The use of ECC to detect transmission errors so that retransmissions (hopefully without errors) can be requested is widely known as "ARQ" (Automatic Repeat Request).
再送信（できればエラーなし）を要求できるように、伝送エラーを検出するためにECCを使用することは、「ARQ」（自動リピートリクエスト）として広く知られています。
When enough ECC information is available to permit the receiver to correct some transmission errors without a retransmission, the approach is known as Forward Error Correction (FEC). Due to the greater complexity of the required ECC and the need to tailor its design to the characteristics of a specific modem and channel, FEC has traditionally been implemented in special-purpose hardware integral to a modem. This effectively makes it part of the physical layer.
再送信なしで受信機がいくつかの伝送エラーを修正できるように十分なECC情報を利用できる場合、アプローチはフォワードエラー補正（FEC）として知られています。必要なECCの複雑さが大きく、特定のモデムとチャネルの特性に合わせて設計を調整する必要性により、FECは従来、モデムに統合された特殊なハードウェアに実装されてきました。これにより、物理的な層の一部になります。
Unlike ARQ, FEC was rarely used for telecommunications outside of space links prior to the 1990s. It is now nearly universal in telephone, cable and DSL modems, digital satellite links, and digital mobile telephones. FEC is also heavily used in optical and magnetic storage where "retransmissions" are not possible.
ARQとは異なり、FECは1990年代以前にスペースリンク以外の通信に使用されませんでした。現在、電話、ケーブルおよびDSLモデム、デジタル衛星リンク、デジタルモバイル電話でほぼ普遍的です。FECは、「再送信」が不可能な光学および磁気ストレージでも頻繁に使用されています。
Some systems use hybrid combinations of ARQ layered atop FEC; V.90 dialup modems (in the upstream direction) with V.42 error control are one example. Most errors are corrected by the trellis (FEC) code within the V.90 modem, and most remaining errors are detected and corrected by the ARQ mechanisms in V.42.
一部のシステムでは、FECの上に層状になったARQのハイブリッド組み合わせを使用しています。v.42エラー制御を備えたV.90ダイヤルアップモデム（上流方向）が1つの例です。ほとんどのエラーは、V.90モデム内のTrellis（FEC）コードによって修正され、残りのほとんどのエラーはV.42のARQメカニズムによって検出および修正されます。
Work is now underway to apply FEC above the physical layer, primarily in connection with reliable multicasting [RFC3048] [RFC3450-RFC3453] where conventional ARQ mechanisms are inefficient or difficult to implement. However, in this discussion, we will assume that if FEC is present, it is implemented within the physical layer.
主に信頼できるマルチキャスト[RFC3048] [RFC3450-RFC3453]に関連して、フィジカルレイヤーの上にFECを適用する作業が進行中です。ただし、この議論では、FECが存在する場合、物理層内に実装されると仮定します。
Depending on the layer in which it is implemented, error control can operate on an end-to-end basis or over a shorter span, such as a single link. TCP is the most important example of an end-to-end protocol that uses an ARQ strategy.
実装されたレイヤーに応じて、エラー制御は、単一のリンクなど、エンドツーエンドベースまたはより短いスパンで動作できます。TCPは、ARQ戦略を使用するエンドツーエンドプロトコルの最も重要な例です。
Many link-layer protocols use ARQ, usually some flavor of HDLC [ISO3309]. Examples include the X.25 link layer, the AX.25 protocol used in amateur packet radio, 802.11 wireless LANs, and the reliable link layer specified in IEEE 802.2.
多くのリンク層プロトコルはARQを使用しており、通常はHDLCのフレーバーです[ISO3309]。例には、X.25リンクレイヤー、アマチュアパケットラジオで使用されるAX.25プロトコル、802.11ワイヤレスLANS、およびIEEE 802.2で指定された信頼できるリンク層が含まれます。
Only end-to-end error recovery can ensure reliable service to the application (see Section 8). However, some subnetworks (e.g., many wireless links) also have link-layer error recovery as a performance enhancement [RFC3366]. For example, many cellular links have small physical frame sizes (< 100 bytes) and relatively high frame loss rates. Relying solely on end-to-end error recovery can clearly yield a performance degradation, as retransmissions across the end-to-end path take much longer to be received than when link layer retransmissions are used. Thus, link-layer error recovery can often increase end-to-end performance. As a result, link-layer and end-to-end recovery often co-exist; this can lead to the possibility of inefficient interactions between the two layers of ARQ protocols.
エンドツーエンドのエラー回復のみが、アプリケーションへの信頼できるサービスを確保できます（セクション8を参照）。ただし、一部のサブネットワーク（多くのワイヤレスリンクなど）には、パフォーマンス向上としてリンク層エラー回復もあります[RFC3366]。たとえば、多くのセルラーリンクには、物理的なフレームサイズが小さく（<100バイト）、フレーム損失率が比較的高くなっています。エンドツーエンドのエラー回復のみに依存すると、エンドツーエンドのパス全体の再送信がリンクレイヤーの再送信が使用される場合よりもはるかに時間がかかるため、パフォーマンスの劣化を明らかに生成できます。したがって、リンク層エラーの回復は、多くの場合、エンドツーエンドのパフォーマンスを向上させる可能性があります。その結果、リンク層とエンドツーエンドの回復がしばしば共存します。これにより、ARQプロトコルの2つの層間の非効率的な相互作用の可能性につながる可能性があります。
This inter-layer "competition" might lead to the following wasteful situation. When the link layer retransmits (parts of) a packet, the link latency momentarily increases. Since TCP bases its retransmission timeout on prior measurements of total end-to-end latency, including that of the link in question, this sudden increase in latency may trigger an unnecessary retransmission by TCP of a packet that the link layer is still retransmitting. Such spurious end-to-end retransmissions generate unnecessary load and reduce end-to-end throughput. As a result, the link layer may even have multiple copies of the same packet in the same link queue at the same time. In general, one could say the competing error recovery is caused by an inner control loop (link-layer error recovery) reacting to the same signal as an outer control loop (end-to-end error recovery) without any coordination between the loops. Note that this is solely an efficiency issue; TCP continues to provide reliable end-to-end delivery over such links.
この層間の「競争」は、次の無駄な状況につながる可能性があります。リンクレイヤーがパケットを再送信すると（一部）、リンクの遅延が一時的に増加します。TCPは、問題のリンクを含む総エンドツーエンドのレイテンシの以前の測定に再送信タイムアウトに基づいているため、この突然のレイテンシの増加は、リンクレイヤーがまだ再送信しているパケットのTCPによる不必要な再送信を引き起こす可能性があります。このような偽のエンドツーエンドの再送信は、不必要な負荷を生成し、エンドツーエンドのスループットを減らします。その結果、リンクレイヤーには、同じリンクキューに同じパケットの複数のコピーが同時にある場合さえあります。一般に、競合するエラー回復は、ループ間の調整なしに外部コントロールループ（エンドツーエンドエラー回復）と同じ信号に反応する内部制御ループ（リンク層エラー回復）によって引き起こされると言えます。これは単に効率の問題であることに注意してください。TCPは、このようなリンクに対して信頼できるエンドツーエンドの配信を引き続き提供しています。
This raises the question of how persistent a link-layer sender should be in performing retransmission [RFC3366]. We define the link-layer (LL) ARQ persistency as the maximum time that a particular link will spend trying to transfer a packet before it can be discarded. This deliberately simplified definition says nothing about the maximum number of retransmissions, retransmission strategies, queue sizes, queuing disciplines, transmission delays, or the like. The reason we use the term LL ARQ persistency, instead of a term such as "maximum link-layer packet holding time," is that the definition closely relates to link-layer error recovery. For example, on links that implement straightforward error recovery strategies, LL ARQ persistency will often correspond to a maximum number of retransmissions permitted per link-layer frame.
これは、リンク層の送信者が再送信を実行することにどれほど持続的であるべきかという問題を提起します[RFC3366]。特定のリンクがパケットを破棄する前にパケットを転送しようとして費やす最大時間として、リンク層（LL）ARQの持続性を定義します。この意図的に簡素化された定義は、再送信の最大数、再送信戦略、キューサイズ、キューイングの分野、送信の遅延などについては何も述べていません。「最大リンクレイヤーパケット保持時間」などの用語ではなく、LL ARQ持続性という用語を使用する理由は、定義がリンク層エラー回復に密接に関連しているためです。たとえば、簡単なエラー回復戦略を実装するリンクでは、LL ARQの持続性は、多くの場合、リンク層フレームごとに許可される最大数の再送信に対応します。
For link layers that do not or cannot differentiate between flows (e.g., due to network layer encryption), the LL ARQ persistency should be small. This avoids any harmful effects or performance degradation resulting from indiscriminate high persistence. A detailed discussion of these issues is provided in [RFC3366].
フローを区別しない、または区別できないリンクレイヤーの場合（たとえば、ネットワークレイヤー暗号化による）、LL ARQの持続性は小さくなければなりません。これにより、無差別の高い持続性に起因する有害な影響やパフォーマンスの劣化が回避されます。これらの問題の詳細な議論は[RFC3366]で提供されています。
However, when a link layer can identify individual flows and apply ARQ selectively [LKJK02], then the link ARQ persistency should be high for a flow using reliable unicast transport protocols (e.g., TCP) and must be low for all other flows. Setting the link ARQ persistency larger than the largest link outage allows TCP to rapidly restore transmission without needing to wait for a retransmission time out. This generally improves TCP performance in the face of transient outages. However, excessively high persistence may be disadvantageous; a practical upper limit of 30-60 seconds may be desirable. Implementation of such schemes remains a research issue. (See also the following section "Recovery from Subnetwork Outages").
ただし、リンク層が個々のフローを識別し、ARQを選択的に適用できる場合[LKJK02]、信頼性の高いユニキャスト輸送プロトコル（例：TCP）を使用してフローのリンクARQ持続性が高く、他のすべてのフローでは低くなければなりません。リンクARQの永続性を最大のリンク停止よりも大きく設定すると、TCPは再送信時間を待つ必要なく伝送を迅速に回復できます。これにより、通常、一時的な停止に直面してTCPパフォーマンスが向上します。ただし、過度に高い持続性は不利な場合があります。30〜60秒の実用的な上限が望ましい場合があります。このようなスキームの実装は、依然として研究問題です。（次のセクション「サブネットワークの停止からの回復」も参照してください）。
Many subnetwork designers have opportunities to reduce the probability of packet loss, e.g., with FEC, ARQ, and interleaving, at the cost of increased delay. TCP performance improves with decreasing loss but worsens with increasing end-to-end delay, so it is important to find the proper balance through analysis and simulation.
多くのサブネットワークデザイナーは、遅延の増加を犠牲にして、FEC、ARQ、およびインターリーブなど、パケット損失の確率を減らす機会があります。TCPのパフォーマンスは損失を減らすと改善しますが、エンドツーエンドの遅延が増加すると悪化するため、分析とシミュレーションを通じて適切なバランスを見つけることが重要です。
Some types of subnetworks, particularly mobile radio, are subject to frequent temporary outages. For example, an active cellular data user may drive or walk into an area (such as a tunnel) that is out of range of any base station. No packets will be delivered successfully until the user returns to an area with coverage.
一部のタイプのサブネットワーク、特にモバイルラジオは、頻繁に一時的な停止の対象となります。たとえば、アクティブなセルラーデータユーザーは、基地局の範囲外のエリア（トンネルなど）を運転または歩いて行くことができます。ユーザーがカバレッジのあるエリアに戻るまで、パケットは正常に配信されません。
The Internet protocols currently provide no standard way for a subnetwork to explicitly notify an upper layer protocol (e.g., TCP) that it is experiencing an outage rather than severe congestion.
現在、インターネットプロトコルは、サブネットワークが重度の輻輳ではなく停止が発生していることを上層層プロトコル（TCPなど）に明示的に通知する標準的な方法を提供していません。
Under these circumstances TCP will, after each unsuccessful retransmission, wait even longer before trying again; this is its "exponential back-off" algorithm. Furthermore, TCP will not discover that the subnetwork outage has ended until its next retransmission attempt. If TCP has backed off, this may take some time. This can lead to extremely poor TCP performance over such subnetworks.
これらの状況では、TCPは、再送信に失敗するたびに、もう一度試してからさらに長く待ちます。これは、その「指数バックオフ」アルゴリズムです。さらに、TCPは、次の再送信の試みまでサブネットワークの停止が終了したことを発見しません。TCPが後退した場合、これには時間がかかる場合があります。これにより、このようなサブネットワークよりもTCPパフォーマンスが非常に低下する可能性があります。
It is therefore highly desirable that a subnetwork subject to outages does not silently discard packets during an outage. Ideally, the subnetwork should define an interface to the next higher layer (i.e., IP) that allows it to refuse packets during an outage, and to automatically ask IP for new packets when it is again able to deliver them. If it cannot do this, then the subnetwork should hold onto at least some of the packets it accepts during an outage and attempt to deliver them when the outage ends. When packets are discarded, IP should be notified so that the appropriate ICMP messages can be sent.
したがって、停止の対象となるサブネットワークが停止中に静かにパケットを破棄しないことは非常に望ましいです。理想的には、サブネットワークは、停止中にパケットを拒否できるようにする次の高レイヤー（つまり、IP）へのインターフェイスを定義し、再び配信できるときに新しいパケットをIPを自動的に尋ねる必要があります。これができない場合は、サブネットワークは、停止中に受け入れるパケットの少なくとも一部を保持し、停止が終了したときにそれらを配信しようとする必要があります。パケットが破棄されたら、適切なICMPメッセージを送信できるようにIPに通知する必要があります。
Note that it is *not* necessary to completely avoid dropping packets during an outage. The purpose of holding onto a packet during an outage, either in the subnetwork or at the IP layer, is so that its eventual delivery will implicitly notify TCP that the subnetwork is again operational. This is to enhance performance, not to ensure reliability -- reliability, as discussed earlier, can only be ensured on an end-to-end basis.
停止中にパケットをドロップすることを完全に避ける必要はないことに注意してください。サブネットワークまたはIPレイヤーのいずれかで、停止中にパケットを保持する目的は、最終的な配信がTCPにサブネットワークが再び動作していることを暗黙的に通知することです。これは、信頼性を確保するのではなく、パフォーマンスを向上させるためです。前述のように、信頼性はエンドツーエンドベースでのみ保証できます。
Only a few packets per TCP connection, including ACKs, need be held in this way to cause the TCP sender to recover from the additional losses once the flow resumes [RFC3366].
ACKを含むTCP接続ごとに少数のパケットのみをこのように保持する必要があります。これは、フローが再開するとTCP送信者が追加の損失から回復するようにする必要があります[RFC3366]。
Because it would be a layering violation (and possibly a performance hit) for IP or a subnetwork layer to look at TCP headers (which would in any event be impossible if IPsec encryption [RFC2401] is in use), it would be reasonable for the IP or subnetwork layers to choose, as a design parameter, some small number of packets that will be retained during an outage.
IPまたはサブネットワークレイヤーのレイヤー違反（およびおそらくパフォーマンスヒット）であるため、TCPヘッダーを調べるためのサブネットワークレイヤー（いずれにしても、IPSEC暗号化[RFC2401]が使用されている場合は不可能です）設計パラメーターとして、停止中に保持される少数のパケットを選択するIPまたはサブネットワークレイヤー。
The TCP [RFC793], UDP [RFC768], ICMP, and IPv4 [RFC791] protocols all use the same simple 16-bit 1's complement checksum algorithm [RFC1071] to detect corrupted packets. The IPv4 header checksum protects only the IPv4 header, while the TCP, ICMP, and UDP checksums provide end-to-end error detection for both the transport pseudo header (including network and transport layer information) and the transport payload data. Protection of the data is optional for applications using UDP [RFC768] for IPv4, but is required for IPv6.
TCP [RFC793]、UDP [RFC768]、ICMP、およびIPv4 [RFC791]プロトコルはすべて、同じ単純な16ビット1の補体チェックサムアルゴリズム[RFC1071]を使用して破損したパケットを検出します。IPv4ヘッダーチェックサムはIPv4ヘッダーのみを保護し、TCP、ICMP、およびUDPチェックサムは、トランスポート擬似ヘッダー（ネットワークおよびトランスポートレイヤー情報を含む）とトランスポートペイロードデータの両方のエンドツーエンドエラー検出を提供します。データの保護は、IPv4にUDP [RFC768]を使用したアプリケーションではオプションですが、IPv6には必要です。
The Internet checksum is not very strong from a coding theory standpoint, but it is easy to compute in software, and various proposals to replace the Internet checksums with stronger checksums have failed. However, it is known that undetected errors can and do occur in packets received by end hosts [SP2000].
インターネットチェックサムはコーディング理論の観点からはそれほど強力ではありませんが、ソフトウェアで計算するのは簡単であり、インターネットチェックサムをより強力なチェックサムに置き換えるさまざまな提案が失敗しました。ただし、検出されていないエラーは、エンドホスト[SP2000]が受信したパケットで発生する可能性があることが知られています。
To reduce processing costs, IPv6 has no IP header checksum. The destination host detects "important" errors in the IP header, such as the delivery of the packet to the wrong destination. This is done by including the IP source and destination addresses (pseudo header) in the computation of the checksum in the TCP or UDP header, a practice already performed in IPv4. Errors in other IPv6 header fields may go undetected within the network; this was considered a reasonable price to pay for a considerable reduction in the processing required by each router, and it was assumed that subnetworks would use a strong link CRC.
処理コストを削減するために、IPv6にはIPヘッダーチェックサムがありません。宛先ホストは、間違った宛先にパケットを配信するなど、IPヘッダーの「重要な」エラーを検出します。これは、IPv4ですでに実行されているプラクティスであるTCPまたはUDPヘッダーのチェックサムの計算にIPソースと宛先アドレス（擬似ヘッダー）を含めることによって行われます。他のIPv6ヘッダーフィールドのエラーは、ネットワーク内で検出されない場合があります。これは、各ルーターが必要とする処理の大幅な削減のために支払う合理的な価格と見なされ、サブネットワークが強力なリンクCRCを使用すると想定されていました。
One way to provide additional protection for an IPv4 or IPv6 header is by the authentication and packet integrity services of the IP Security (IPsec) protocol [RFC2401]. However, this may not be a choice available to the subnetwork designer.
IPv4またはIPv6ヘッダーに追加の保護を提供する1つの方法は、IPセキュリティ（IPSEC）プロトコル[RFC2401]の認証とパケット整合性サービスです。ただし、これはサブネットワークデザイナーが利用できる選択肢ではない場合があります。
Most subnetworks implement error detection just above the physical layer. Packets corrupted in transmission are detected and discarded before delivery to the IP layer. A 16-bit cyclic redundancy check (CRC) is usually the minimum for error detection. This is significantly more robust against most patterns of errors than the 16-bit Internet checksum. Note that the error detection properties of a specific CRC code diminish with increasing frame size. The Point-to-Point Protocol [RFC1662] requires support of a 16-bit CRC for each link frame, with a 32-bit CRC as an option. (PPP is often used in conjunction with a dialup modem, which provides its own error control). Other subnetworks, including 802.3/Ethernet, AAL5/ATM, FDDI, Token Ring, and PPP over SONET/SDH all use a 32-bit CRC. Many subnetworks can also use other mechanisms to enhance the error detection capability of the link CRC (e.g., FEC in dialup modems, mobile radio and satellite channels).
ほとんどのサブネットワークは、物理レイヤーのすぐ上にエラー検出を実装しています。トランスミッションで破損したパケットは、IPレイヤーに配信する前に検出および破棄されます。通常、16ビット環状冗長チェック（CRC）は、通常、エラー検出の最小です。これは、16ビットのインターネットチェックサムよりも、ほとんどのエラーパターンに対して非常に堅牢です。特定のCRCコードのエラー検出プロパティは、フレームサイズが増加すると減少することに注意してください。ポイントツーポイントプロトコル[RFC1662]には、各リンクフレームの16ビットCRCのサポートが必要であり、オプションとして32ビットCRCがあります。（PPPは、多くの場合、Dialup Modemと組み合わせて使用され、独自のエラーコントロールを提供します）。SONET/SDHを介した802.3/イーサネット、AAL5/ATM、FDDI、トークンリング、PPPを含む他のサブネットワークはすべて32ビットCRCを使用しています。多くのサブネットワークは、他のメカニズムを使用して、リンクCRCのエラー検出機能を強化することもできます（たとえば、ダイヤルアップモデム、モバイル無線、衛星チャネルのFEC）。
Any new subnetwork designed to carry IP should therefore provide error detection for each IP packet that is at least as strong as the 32-bit CRC specified in [ISO3309]. While this will achieve a very low undetected packet error rate due to transmission errors, it will not (and need not) achieve a very low packet loss rate as the Internet protocols are better suited to dealing with lost packets than to dealing with corrupted packets [SRC81].
したがって、IPを運ぶように設計された新しいサブネットワークは、[ISO3309]で指定された32ビットCRCと同じくらい強い各IPパケットのエラー検出を提供する必要があります。これにより、送信エラーによる非常に低い検出されないパケットエラー率が得られますが、インターネットプロトコルは破損したパケットを処理するよりも、失われたパケットを扱うのに適しているため、非常に低いパケット損失率を達成することはできません（必要ではありません）src81]。
Packet corruption may be, and is, also caused by bugs in host and router hardware and software. Even if every subnetwork implemented strong error detection, it is still essential that end-to-end checksums are used at the receiving end host [SP2000].
パケットの破損は、ホストおよびルーターのハードウェアとソフトウェアのバグによって引き起こされる場合があります。すべてのサブネットワークが強力なエラー検出を実装したとしても、受信エンドホスト[SP2000]でエンドツーエンドのチェックサムを使用することが依然として不可欠です。
Designers of complex subnetworks consisting of internal links and packet switches should consider implementing error detection on an edge-to-edge basis to cover an entire SNDU (or IP packet). A CRC would be generated at the entry point to the subnetwork and checked at the exit endpoint. This may be used instead of, or in combination with, error detection at the interface to each physical link. An edge-to-edge check has the significant advantage of protecting against errors introduced anywhere within the subnetwork, not just within its transmission links. Examples of this approach include the way in which the Ethernet CRC-32 is handled by LAN bridges [802.1D]. ATM AAL5 [ITU-I363] also uses an edge-to-edge CRC-32.
内部リンクとパケットスイッチで構成される複雑なサブネットワークの設計者は、SNDU（またはIPパケット）全体をカバーするために、エッジツーエッジベースでエラー検出を実装することを検討する必要があります。CRCは、サブネットワークへのエントリポイントで生成され、Exitエンドポイントでチェックされます。これは、各物理リンクへのインターフェイスでエラー検出の代わりに、または組み合わせて使用できます。エッジツーエッジチェックには、送信リンク内だけでなく、サブネットワーク内のどこにでも導入されたエラーから保護するという大きな利点があります。このアプローチの例には、イーサネットCRC-32がLAN Bridges [802.1d]によって処理される方法が含まれます。ATM AAL5 [ITU-I363]もエッジツーエッジCRC-32を使用しています。
Some specific applications may be tolerant of residual errors in the data they exchange, but removal of the link CRC may expose the network to an undesirable increase in undetected errors in the IP and transport headers. Applications may also require a high level of error protection for control information exchanged by protocols acting above the transport layer. One example is a voice codec, which is robust against bit errors in the speech samples. For such mechanisms to work, the receiving application must be able to tolerate receiving corrupted data. This also requires that an application uses a mechanism to signal that payload corruption is permitted and to indicate the coverage (headers and data) required to be protected by the subnetwork CRC. The UDP-Lite protocol [RFC3828] is the first Internet standards track transport protocol supporting partial payload protection. Receipt of corrupt data by arbitrary application protocols carries a serious danger that a subnet delivers data with errors that remain undetected by the application and hence corrupt the communicated data [SRC81].
一部の特定のアプリケーションは、交換するデータの残留エラーに耐性がある場合がありますが、リンクCRCの削除により、ネットワークがIPおよびトランスポートヘッダーの検出されないエラーの望ましくない増加にさらされる可能性があります。また、アプリケーションは、輸送層の上に作用するプロトコルによって交換される制御情報のために、高レベルのエラー保護を必要とする場合があります。1つの例は音声コーデックです。これは、音声サンプルのビットエラーに対して堅牢です。このようなメカニズムが機能するためには、受信アプリケーションは、破損したデータの受信に耐えることができなければなりません。これには、アプリケーションがメカニズムを使用して、ペイロード腐敗が許可されていることを信号し、サブネットワークCRCによって保護するために必要なカバレッジ（ヘッダーとデータ）を示す必要があります。UDP-Liteプロトコル[RFC3828]は、部分的なペイロード保護をサポートする最初のインターネット標準トランスポートプロトコルです。任意のアプリケーションプロトコルによる破損したデータの受信には、サブネットがアプリケーションによって検出されないままであるため、通信データを破損するエラーでデータを配信するという深刻な危険があります[SRC81]。
One of TCP's functions is end-host based congestion control for the Internet. This is a critical part of the overall stability of the Internet, so it is important that link-layer designers understand TCP's congestion control algorithms.
TCPの機能の1つは、インターネットのエンドホストベースの混雑制御です。これは、インターネットの全体的な安定性の重要な部分であるため、リンク層の設計者がTCPの混雑制御アルゴリズムを理解することが重要です。
TCP assumes that, at the most abstract level, the network consists of links and queues. Queues provide output-buffering on links that are momentarily oversubscribed. They smooth instantaneous traffic bursts to fit the link bandwidth. When demand exceeds link capacity long enough to fill the queue, packets must be dropped. The traditional action of dropping the most recent packet ("tail dropping") is no longer recommended [RFC2309] [RFC2914], but it is still widely practiced.
TCPは、最も抽象的なレベルで、ネットワークはリンクとキューで構成されていると想定しています。キューは、瞬間的に過剰にサブスクライブされるリンクで出力バッファリングを提供します。それらは、リンク帯域幅に適合するために瞬時の交通が滑らかになります。需要がキューを埋めるのに十分な長さのリンク容量を超える場合、パケットをドロップする必要があります。最新のパケット（「テールドロップ」）を削除する従来のアクションは、[RFC2309] [RFC2914]を推奨しなくなりましたが、それでも広く実践されています。
TCP uses sequence numbering and acknowledgments (ACKs) on an end-to-end basis to provide reliable, sequenced delivery. TCP ACKs are cumulative, i.e., each implicitly ACKs every segment received so far. If a packet with an unexpected sequence number is received, the ACK field in the packets returned by the receiver will cease to advance. Using an optional enhancement, TCP can send selective acknowledgments (SACKs) [RFC2018] to indicate which segments have arrived at the receiver.
TCPは、シーケンス番号と謝辞（ACK）をエンドツーエンドベースで使用して、信頼できるシーケンスの配信を提供します。TCP Acksは累積的です。つまり、それぞれがこれまでに受けたすべてのセグメントが暗黙的にAcksです。予期しないシーケンス番号を備えたパケットが受信された場合、受信機によって返されるパケット内のACKフィールドは前進しなくなります。オプションの拡張機能を使用して、TCPは選択的謝辞（Sacks）[RFC2018]を送信して、受信機に到着したセグメントを示します。
Since the most common cause of packet loss is congestion, TCP treats packet loss as an indication of potential Internet congestion along the path between TCP end hosts. This happens automatically, and the subnetwork need not know anything about IP or TCP. A subnetwork node simply drops packets whenever it must, though some packet-dropping strategies (e.g., RED) are more fair to competing flows than others.
パケット損失の最も一般的な原因は混雑であるため、TCPはTCPエンドホスト間のパスに沿った潜在的なインターネット輻輳の兆候としてパケット損失を扱います。これは自動的に発生し、サブネットワークはIPまたはTCPについて何も知る必要はありません。サブネットワークノードは、必要な場合はいつでもパケットをドロップするだけですが、一部のパケットドロップ戦略（たとえば、赤）は、他のパケットよりも競合するフローにとってより公平です。
TCP recovers from packet losses in two different ways. The most important mechanism is the retransmission timeout. If an ACK fails to arrive after a certain period of time, TCP retransmits the oldest unacked packet. Taking this as a hint that the network is congested, TCP waits for the retransmission to be ACKed before it continues, and it gradually increases the number of packets in flight as long as a timeout does not occur again.
TCPは、2つの異なる方法でパケットの損失から回復します。最も重要なメカニズムは、再送信タイムアウトです。ACKが一定期間後に到着しなかった場合、TCPは最も古い未梱包のパケットを再送信します。これをネットワークが混雑しているというヒントとして、TCPは再送信が継続する前にAckedが順調に進むのを待っており、タイムアウトが再び発生しない限り、飛行中のパケットの数を徐々に増やします。
A retransmission timeout can impose a significant performance penalty, as the sender is idle during the timeout interval and restarts with a congestion window of one TCP segment following the timeout. To allow faster recovery from the occasional lost packet in a bulk transfer, an alternate scheme, known as "fast recovery", was introduced [RFC2581] [RFC2582] [RFC2914] [TCPF98].
再送信タイムアウトは、タイムアウト間隔中に送信者がアイドル状態であり、タイムアウト後の1つのTCPセグメントの輻輳ウィンドウで再起動するため、大きなパフォーマンスペナルティを課す可能性があります。バルク転送で時折失われたパケットからの回復をより速くするために、「高速回復」として知られる代替スキームが導入されました[RFC2581] [RFC2582] [RFC2914] [TCPF98]。
Fast recovery relies on the fact that when a single packet is lost in a bulk transfer, the receiver continues to return ACKs to subsequent data packets that do not actually acknowledge any newly-received data. These are known as "duplicate acknowledgments" or "dupacks". The sending TCP can use dupacks as a hint that a packet has been lost and retransmit it without waiting for a timeout. Dupacks effectively constitute a negative acknowledgment (NAK) for the packet sequence number in the acknowledgment field. TCP waits until a certain number of dupacks (currently 3) are seen prior to assuming a loss has occurred; this helps avoid an unnecessary retransmission during out-of-sequence delivery.
高速回復は、単一のパケットがバルク転送で失われた場合、レシーバーは、新たに推定されたデータを実際に認めていない後続のデータパケットにACKを返し続けるという事実に依存しています。これらは、「重複謝辞」または「デュパック」として知られています。送信TCPは、パケットが失われたというヒントとしてDupacksを使用し、タイムアウトを待たずに再送信できます。Dupacksは、確認フィールドのパケットシーケンス番号の否定的な確認（NAK）を効果的に構成します。TCPは、損失が発生したと仮定する前に、特定の数のデュパック（現在3）が見られるまで待機します。これにより、シーケンス外配達中の不必要な再送信を回避できます。
A technique called "Explicit Congestion Notification" (ECN) [RFC3168] allows routers to directly signal congestion to hosts without dropping packets. This is done by setting a bit in the IP header. Since ECN support is likely to remain optional, the lack of an ECN bit must *never* be interpreted as a lack of congestion. Thus, for the foreseeable future, TCP must interpret a lost packet as a signal of congestion.
「明示的な混雑通知」（ECN）[RFC3168]と呼ばれる手法により、ルーターはパケットをドロップせずにホストに輻輳を直接通知することができます。これは、IPヘッダーに少し設定することで行われます。ECNサポートはオプションのままである可能性が高いため、ECNビットの欠如は、渋滞の欠如と解釈されることはありません。したがって、近い将来、TCPは失われたパケットを輻輳の信号として解釈する必要があります。
The TCP "congestion avoidance" [RFC2581] algorithm maintains a congestion window (cwnd) controlling the amount of data TCP may have in flight at any moment. Reducing cwnd reduces the overall bandwidth obtained by the connection; similarly, raising cwnd increases performance, up to the limit of the available capacity.
TCPの「輻輳回避」[RFC2581]アルゴリズムは、TCPがいつでも飛行中に持っているデータの量を制御する混雑ウィンドウ（CWND）を維持しています。CWNDを減らすと、接続によって得られた全体的な帯域幅が減少します。同様に、CWNDを上げると、利用可能な容量の限界までパフォーマンスが向上します。
TCP probes for available network capacity by initially setting cwnd to one or two packets and then increasing cwnd by one packet for each ACK returned from the receiver. This is TCP's "slow start" mechanism. When a packet loss is detected (or congestion is signaled by other mechanisms), cwnd is reset to one and the slow start process is repeated until cwnd reaches one half of its previous setting before the reset. Cwnd continues to increase past this point, but at a much slower rate than before. If no further losses occur, cwnd will ultimately reach the window size advertised by the receiver.
最初にCWNDを1つまたは2つのパケットに設定し、レシーバーから返された各ACKに対して1つのパケットでCWNDを増やすことにより、利用可能なネットワーク容量のTCPプローブ。これは、TCPの「スロースタート」メカニズムです。パケットの損失が検出される（または他のメカニズムによって輻輳が通知される）場合、CWNDが1つにリセットされ、CWNDがリセットの前に以前の設定の半分に達するまで遅いスタートプロセスが繰り返されます。CWNDはこのポイントを超えて増加し続けていますが、以前よりもはるかに遅い速度で増加しています。それ以上の損失が発生しない場合、CWNDは最終的にレシーバーによって宣伝されたウィンドウサイズに到達します。
This is an "Additive Increase, Multiplicative Decrease" (AIMD) algorithm. The steep decrease of cwnd in response to congestion provides for network stability; the AIMD algorithm also provides for fairness between long running TCP connections sharing the same path.
これは、「加法の増加、乗法減少」（AIMD）アルゴリズムです。混雑に応じてCWNDの急激な減少は、ネットワークの安定性を提供します。AIMDアルゴリズムは、同じパスを共有する長い実行TCP接続間の公平性も提供します。
Caveat
警告
Here we present a current "state-of-the-art" understanding of TCP performance. This analysis attempts to characterize the performance of TCP connections over links of varying characteristics.
ここでは、TCPパフォーマンスに関する現在の「最先端の」理解を紹介します。この分析では、さまざまな特性のリンク上のTCP接続のパフォーマンスを特徴付けようとします。
Link designers may wish to use the techniques in this section to predict what performance TCP/IP may achieve over a new link-layer design. Such analysis is encouraged. Because this is a relatively new analysis, and the theory is based on single-stream TCP connections under "ideal" conditions, it should be recognized that the results of such analysis may differ from actual performance in the Internet. That being said, we have done our best to provide the designers with helpful information to get an accurate picture of the capabilities and limitations of TCP under various conditions.
Link Designersは、このセクションのテクニックを使用して、新しいリンク層設計でTCP/IPが達成できるパフォーマンスを予測することをお勧めします。このような分析が奨励されています。これは比較的新しい分析であり、理論は「理想的な」条件下でのシングルストリームTCP接続に基づいているため、このような分析の結果はインターネットの実際のパフォーマンスとは異なる可能性があることを認識する必要があります。そうは言っても、さまざまな条件下でTCPの機能と制限を正確に把握するために、デザイナーに役立つ情報を提供するために最善を尽くしました。
The performance of TCP's AIMD Congestion Avoidance algorithm has been extensively analyzed. The current best formula for the performance of the specific algorithms used by Reno TCP (i.e., the TCP specified in [RFC2581]) is given by Padhye, et al. [PFTK98]. This formula is:
TCPのAIMD混雑回避アルゴリズムのパフォーマンスが広範囲に分析されています。Reno TCP（つまり、[RFC2581]で指定されたTCP）が使用する特定のアルゴリズムのパフォーマンスのための現在の最良の式は、Padhyeなどによって与えられています。[PFTK98]。この式は次のとおりです。
MSS
BW = --------------------------------------------------------
RTT*sqrt(1.33*p) + RTO*p*[1+32*p^2]*min[1,3*sqrt(.75*p)]
where
ただし
BW is the maximum TCP throughout achievable by an individual TCP flow MSS is the TCP segment size being used by the connection RTT is the end-to-end round trip time of the TCP connection RTO is the packet timeout (based on RTT) p is the packet loss rate for the path (i.e., .01 if there is 1% packet loss)
BWは個々のTCPフローによって達成可能な最大TCPです。MSSは接続で使用されているTCPセグメントサイズRTTがTCP接続のエンドツーエンドのラウンドトリップタイムですRTOはパケットタイムアウト（RTTに基づく）です。パスのパケット損失率（つまり、1％のパケット損失がある場合、.01）
Note that the speed of the links making up the Internet path does not explicitly appear in this formula. Attempting to send faster than the slowest link in the path causes the queue to grow at the transmitter driving the bottleneck. This increases the RTT, which in turn reduces the achievable throughput.
インターネットパスを構成するリンクの速度は、この式に明示的に表示されないことに注意してください。パスで最も遅いリンクよりも速く送信しようとすると、ボトルネックを駆動するトランスミッターでキューが成長します。これにより、RTTが増加し、達成可能なスループットが減少します。
This is currently considered to be the best approximate formula for Reno TCP performance. A further simplification of this formula is generally made by assuming that RTO is approximately 5*RTT.
これは現在、リノTCPパフォーマンスの最良のおおよその式と見なされています。この式のさらなる簡素化は、一般に、RTOが約5*RTTであると仮定することにより行われます。
TCP is constantly being improved. A simpler formula, which gives an upper bound on the performance of any AIMD algorithm which is likely to be implemented in TCP in the future, was derived by Ott, et al. [MSMO97].
TCPは常に改善されています。将来、TCPで実装される可能性が高いAIMDアルゴリズムのパフォーマンスに上限を与えるよりシンプルな式は、Ott、et al。[MSMO97]。
MSS 1
BW = C --- -------
RTT sqrt(p)
where C is 0.93.
ここで、Cは0.93です。
Both formulae assume that the TCP Receiver Window is not limiting the performance of the connection. Because the receiver window is entirely determined by end-hosts, we assume that hosts will maximize the announced receiver window to maximize their network performance.
両方の式は、TCPレシーバーウィンドウが接続のパフォーマンスを制限していないと想定しています。レシーバーウィンドウはエンドホストによって完全に決定されるため、ホストが発表されたレシーバーウィンドウを最大化してネットワークパフォーマンスを最大化すると仮定します。
Both of these formulae allow BW to become infinite if there is no loss. However, an Internet path will drop packets at bottlenecked queues if the load is too high. Thus, a completely lossless TCP/IP network can never occur (unless the network is being underutilized).
これらの式はどちらも、損失がない場合、BWが無限になります。ただし、負荷が高すぎると、インターネットパスがボトルネックされたキューでパケットをドロップします。したがって、完全にロスレスTCP/IPネットワークは発生することはありません（ネットワークが十分に活用されていない限り）。
The RTT used is the arithmetic average, including queuing delays.
使用されるRTTは、キューイングの遅延を含む算術平均です。
The formulae are for a single TCP connection. If a path carries many TCP connections, each will follow the formulae above independently.
式は、単一のTCP接続用です。パスに多くのTCP接続がある場合、それぞれが上記の式を個別に追跡します。
The formulae assume long-running TCP connections. For connections that are extremely short (<10 packets) and don't lose any packets, performance is driven by the TCP slow-start algorithm. For connections of medium length, where on average only a few segments are lost, single connection performance will actually be slightly better than given by the formulae above.
式は、長期にわたるTCP接続を想定しています。非常に短い（10 <10パケット）、パケットを失うことのない接続の場合、パフォーマンスはTCPスロースタートアルゴリズムによって駆動されます。平均して少数のセグメントのみが失われる中程度の長さの接続の場合、単一の接続性能は、実際には上記の式で与えられるよりもわずかに優れています。
The difference between the simple and complex formulae above is that the complex formula includes the effects of TCP retransmission timeouts. For very low levels of packet loss (significantly less than 1%), timeouts are unlikely to occur, and the formulae lead to very similar results. At higher packet losses (1% and above), the complex formula gives a more accurate estimate of performance (which will always be significantly lower than the result from the simple formula).
上記のシンプルな式と複雑な式の違いは、複雑な式にTCP再送信タイムアウトの効果が含まれることです。非常に低いレベルのパケット損失（1％未満）の場合、タイムアウトが発生する可能性は低く、フォーミュラは非常に類似した結果につながります。より高いパケット損失（1％以上）では、複雑な式はパフォーマンスのより正確な推定値を提供します（これは常に単純な式の結果よりも著しく低くなります）。
Note that these formulae break down as p approaches 100%.
Pが100％に近づくと、これらの式が分解することに注意してください。
Consider the following example:
次の例を考えてみましょう。
A designer invents a new wireless link layer which, on average, loses 1% of IP packets. The link layer supports packets of up to 1040 bytes, and has a one-way delay of 20 msec.
デザイナーは、平均してIPパケットの1％を失う新しいワイヤレスリンクレイヤーを発明します。リンクレイヤーは、最大1040バイトのパケットをサポートしており、20ミリ秒の一元配置遅延があります。
If this link were to be used on an Internet path with a round trip time greater than 80ms, the upper bound may be computed by:
このリンクが80ミリ秒を超える往復時間を持つインターネットパスで使用される場合、上限は以下で計算できます。
For MSS, use 1000 bytes to exclude the 40 bytes of minimum IPv4 and TCP headers.
MSSの場合、1000バイトを使用して、最小IPv4およびTCPヘッダーの40バイトを除外します。
For RTT, use 120 msec (80 msec for the Internet part, plus 20 msec each way for the new wireless link).
RTTの場合、120ミリ秒（インターネット部品に80ミリ秒、新しいワイヤレスリンクにはそれぞれ20ミリ秒）を使用します。
For p, use .01. For C, assume 1.
Pの場合、.01を使用します。Cの場合、1を仮定します。
The simple formula gives:
単純な式に：
BW = (1000 * 8 bits) / (.120 sec * sqrt(.01)) = 666 kbit/sec
The more complex formula gives:
より複雑なフォーミュラは次のとおりです。
BW = 402.9 kbit/sec
bw = 402.9 kbit/sec
If this were a 2 Mb/s wireless LAN, the designers might be somewhat disappointed.
これが2 MB/SワイヤレスLANであれば、デザイナーはややがっかりするかもしれません。
Some observations on performance:
パフォーマンスに関するいくつかの観察：
1. We have assumed that the packet losses on the link layer are interpreted as congestion by TCP. This is a "fact of life" that must be accepted.
1. リンクレイヤーのパケット損失は、TCPによる混雑として解釈されると想定しています。これは受け入れなければならない「人生の事実」です。
2. The equations for TCP performance are all expressed in terms of packet loss, but many subnetwork designers think in terms of bit-error ratio. *If* channel bit errors are independent, then the probability of a packet being corrupted is:
2. TCPパフォーマンスの方程式はすべてパケット損失の観点から表されますが、多くのサブネットワークデザイナーはビットエラーの比率で考えています。**チャネルビットエラーが独立している場合、パケットが破損する確率は次のとおりです。
p = 1 - ([1 - BER]^[FRAME_SIZE*8])
Here we assume FRAME_SIZE is in bytes and "^" represents exponentiation. It includes the user data and all headers (TCP,IP and subnetwork). (Note: this analysis assumes the subnetwork does not perform ARQ or transparent fragmentation [RFC3366].) If the inequality
ここでは、frame_sizeがバイトで、「^」が指数を表すと仮定します。ユーザーデータとすべてのヘッダー（TCP、IP、およびサブネットワーク）が含まれます。（注：この分析では、サブネットワークがARQまたは透明な断片化を実行しないと仮定します[RFC3366]。）不平等の場合
BER * [FRAME_SIZE*8] << 1
holds, the packet loss probability p can be approximated by:
ホールド、パケット損失確率pは以下で近似できます。
p = BER * [FRAME_SIZE*8]
These equations can be used to apply BER to the performance equations above.
これらの方程式を使用して、上記のパフォーマンス方程式にBERを適用できます。
Note that FRAME_SIZE can vary from one packet to the next. Small packets (such as TCP acks) generally have a smaller probability of packet error than, say, a TCP packet carrying one MSS (maximum segment size) of user data. A flow of small TCP acks can be expected to be slightly more reliable than a stream of larger TCP data segments.
frame_sizeは、パケットから次のパケットまで変化する可能性があることに注意してください。小さなパケット（TCP Acksなど）は、一般に、ユーザーデータの1つのMSS（最大セグメントサイズ）を運ぶTCPパケットよりもパケットエラーの確率が小さくなります。小さなTCP Acksの流れは、より大きなTCPデータセグメントのストリームよりもわずかに信頼性が高いと予想されます。
It bears repeating that the above analysis assumes that bit errors are statistically independent. Because this is not true for many real links, our computation of p is actually an upper bound, not the exact probability of packet loss.
上記の分析では、ビットエラーが統計的に独立していると想定していることが繰り返されます。これは多くの実際のリンクに当てはまるわけではないため、Pの計算は実際には上限であり、パケット損失の正確な確率ではありません。
There are many reasons why bit errors are not independent on real links. Many radio links are affected by propagation fading or by interference that lasts over many bit times. Also, links with Forward Error Correction (FEC) generally have very non-uniform bit error distributions that depend on the type of FEC, but in general the uncorrected errors tend to occur in bursts even when channel symbol errors are independent. In all such cases, our computation of p from BER can only place an upper limit on the packet loss rate.
ビットエラーが実際のリンクで独立していない理由はたくさんあります。多くの無線リンクは、伝播フェージングまたは多くのビットにわたって持続する干渉の影響を受けます。また、フォワードエラー補正（FEC）とのリンクは、一般にFECのタイプに依存する非常に不均一なビットエラー分布を持っていますが、一般に、補正されていないエラーは、チャネルシンボルエラーが独立している場合でもバーストで発生する傾向があります。このような場合、BERからのPの計算は、パケット損失率に上限のみを配置できます。
If the distribution of errors under the FEC scheme is known, one could apply the same type of analysis as above, using the correct distribution function for the BER. It is more likely in these FEC cases, however, that empirical methods are needed to determine the actual packet loss rate.
FECスキームに基づくエラーの分布がわかっている場合、BERの正しい分布関数を使用して、上記と同じタイプの分析を適用できます。ただし、これらのFECの場合、実際のパケット損失率を決定するために経験的な方法が必要である可能性が高くなります。
3. Note that the packet size plays an important role. If the subnetwork loss characteristics are such that large packets have the same probability of loss as smaller packets, then larger packets will yield improved performance.
3. パケットサイズが重要な役割を果たすことに注意してください。サブネットワークの損失特性が、大きなパケットがより小さなパケットと同じ損失の確率を持つようになった場合、パケットが大きくなるとパフォーマンスが向上します。
4. We have chosen a specific RTT that might occur on a wide-area Internet path within the USA. It is important to recognize that a variety of RTT values are experienced in the Internet.
4. 米国内の広い地域のインターネットパスで発生する可能性のある特定のRTTを選択しました。さまざまなRTT値がインターネットで経験されていることを認識することが重要です。
For example, RTTs are typically less than 10 msec in a wired LAN environment when communicating with a local host. International connections may have RTTs of 200 msec or more. Modems and other low-capacity links can add considerable delay due to their long packet transmission (serialisation) times.
たとえば、RTTは通常、ローカルホストと通信するときに有線LAN環境では10ミリ秒未満です。国際的なつながりには、200ミリ秒以上のRTTがある場合があります。モデムやその他の低容量リンクは、長いパケット送信（シリアル化）時間のためにかなりの遅延を追加する可能性があります。
Links over geostationary repeater satellites have one-way speed-of-light delays of around 250ms, a minimum of 125ms propagation delay up to the satellite and 125ms down. The RTT of an end-to-end TCP connection that includes such a link can be expected to be greater than 250ms.
Geostationary Repeater Satellitesのリンクには、約250ミリ秒の一元配置速度遅延があり、衛星までの最低125ミリ秒の伝播遅延と125msダウンがあります。このようなリンクを含むエンドツーエンドのTCP接続のRTTは、250msを超えると予想されます。
Queues on heavily-congested links may back up, increasing RTTs. Finally, virtual private networks (VPNs) and other forms of encryption and tunneling can add significant end-to-end delay to network connections.
大量のリンクのキューはバックアップされ、RTTが増加する可能性があります。最後に、仮想プライベートネットワーク（VPN）およびその他の形式の暗号化とトンネルは、ネットワーク接続に大幅なエンドツーエンド遅延を追加する可能性があります。
It is generally recognized that specific service guarantees are needed to support real-time multimedia, toll-quality telephony, and other performance-critical applications. The provision of such Quality of Service guarantees in the Internet is an active area of research and standardization. The IETF has not converged on a single service model, set of services, or single mechanism that will offer useful guarantees to applications and be scalable to the Internet. Indeed, the IETF does not have a single definition of Quality of Service. [RFC2990] represents a current understanding of the challenges in architecting QoS for the Internet.
一般に、リアルタイムのマルチメディア、Toll品質のテレフォニー、およびその他のパフォーマンスクリティカルなアプリケーションをサポートするには、特定のサービス保証が必要であることが認識されています。インターネットでのこのような品質のサービス保証の提供は、研究と標準化の積極的な分野です。IETFは、単一のサービスモデル、サービスのセット、またはアプリケーションに有用な保証を提供し、インターネットにスケーラブルになる単一のメカニズムに収束していません。実際、IETFには、サービス品質の定義が1つありません。[RFC2990]は、インターネットのQoSをアーキテクテクティブする際の課題に対する現在の理解を表しています。
There are presently two architectural approaches to providing mechanisms for QoS support in the Internet.
現在、インターネットでQoSサポートのメカニズムを提供するための2つのアーキテクチャアプローチがあります。
IP Integrated Services (Intserv) [RFC1633] provides fine-grained service guarantees to individual flows. Flows are identified by a flow specification (flowspec), which creates a stateful association between individual packets by matching fields in the packet header. Capacity is reserved for the flow, and appropriate traffic conditioning and scheduling is installed in routers along the path. The ReSerVation Protocol (RSVP) [RFC2205] [RFC2210] is usually, but need not necessarily be, used to install the flow QoS state. Intserv defines two services, in addition to the Default (best effort) service.
IP Integrated Services（INTSERV）[RFC1633]は、個々のフローに微調整されたサービス保証を提供します。フローは、パケットヘッダー内のフィールドを一致させることにより、個々のパケット間のステートフルな関連を作成するフロー仕様（FlowsPec）によって識別されます。容量はフローのために予約されており、パスに沿ってルーターに適切なトラフィックコンディショニングとスケジューリングがインストールされます。予約プロトコル（RSVP）[RFC2205] [RFC2210]は、通常、フローQoS状態のインストールに使用される必要はありませんが、必ずしも使用する必要はありません。IntServは、デフォルト（ベストエフェクション）サービスに加えて、2つのサービスを定義します。
1. Guaranteed Service (GS) [RFC2212] offers hard upper bounds on delay to flows that conform to a traffic specification (TSpec). It uses a fluid-flow model to relate the TSpec and reserved bandwidth (RSpec) to variable delay. Non-conforming packets are forwarded on a best-effort basis.
1. 保証されたサービス（GS）[RFC2212]は、トラフィック仕様（TSPEC）に準拠するフローへの遅延時のハード上限を提供します。流体流量モデルを使用して、TSPECと予約帯域幅（RSPEC）をさまざまな遅延に関連付けます。不適合パケットは、最良のエフォルトベースで転送されます。
2. Controlled Load Service (CLS) [RFC2211] offers delay and packet loss equivalent to that of an unloaded network to flows that conform to a TSpec, but no hard bounds. Non-conforming packets are forwarded on a best-effort basis.
2. 制御されたロードサービス（CLS）[RFC2211]は、TSPECに適合するがハードバウンドに適合するフローに加えて、アンロードされたネットワークの遅延とパケット損失を提供します。不適合パケットは、最良のエフォルトベースで転送されます。
Intserv requires installation of state information in every participating router. Performance guarantees cannot be made unless this state is present in every router along the path. This, along with RSVP processing and the need for usage-based accounting, is believed to have scalability problems, particularly in the core of the Internet [RFC2208].
INTSERVには、参加するすべてのルーターに状態情報をインストールする必要があります。パスに沿ったすべてのルーターにこの状態が存在しない限り、パフォーマンス保証は行うことはできません。これは、RSVP処理と使用法ベースの会計の必要性とともに、特にインターネットの中核であるスケーラビリティの問題があると考えられています[RFC2208]。
IP Differentiated Services (Diffserv) [RFC2475] provides a "toolkit" offering coarse-grained controls to aggregates of flows. Diffserv in itself does *not* provide QoS guarantees, but can be used to construct services with QoS guarantees across a Diffserv domain. Diffserv attempts to address the scaling issues associated with Intserv by requiring state awareness only at the edge of a Diffserv domain. At the edge, packets are classified into flows, and the flows are conditioned (marked, policed, or shaped) to a traffic conditioning specification (TCS). A Diffserv Codepoint (DSCP), identifying a per-hop behavior (PHB), is set in each packet header. The DSCP is carried in the DS-field, subsuming six bits of the former Type-of-Service (ToS) byte [RFC791] of the IP header [RFC2474]. The PHB denotes the forwarding behavior to be applied to the packet in each node in the Diffserv domain. Although there is a "recommended" DSCP associated with each PHB, the mappings from DSCPs to PHBs are defined by the DS-domain. In fact, there can be several DSCPs associated with the same PHB. Diffserv presently defines three PHBs.
IP差別化されたサービス（DIFFSERV）[RFC2475]は、流れの集合体に粗粒のコントロールを提供する「ツールキット」を提供します。DIFFSERV自体は、QoS保証を提供しませんが、QoS保証を提供しませんが、DiffServドメイン全体でQoS保証を使用してサービスを構築するために使用できます。Diffservは、Diffservドメインの端でのみ州の認識を要求することにより、IntServに関連するスケーリングの問題に対処しようとします。エッジでは、パケットはフローに分類され、流れはトラフィックコンディショニング仕様（TCS）に対して条件付け（マーク、ポリシング、または形作られています）。HOPごとの動作（PHB）を識別するDiffServ CodePoint（DSCP）が各パケットヘッダーに設定されています。DSCPはDS-Fieldに運ばれ、IPヘッダー[RFC2474]の以前のサービスタイプ（TOS）バイト[RFC791]の6ビットを吸収します。PHBは、diffservドメインの各ノードのパケットに適用される転送動作を示します。各PHBに関連付けられた「推奨」DSCPがありますが、DSCPからPHBへのマッピングはDSドメインによって定義されます。実際、同じPHBに関連するいくつかのDSCPがあります。Diffservは現在、3つのPHBを定義しています。
1. The class selector PHB [RFC2474] replaces the IP precedence field of the former ToS byte. It offers relative forwarding priorities.
1. クラスセレクターPHB [RFC2474]は、前者のTOSバイトのIP優先順位フィールドを置き換えます。相対的な転送の優先順位を提供します。
2. The Expedited Forwarding (EF) PHB [RFC3246] [RFC3248] guarantees that packets will have a well-defined minimum departure rate which, if not exceeded, ensures that the associated queues are short or empty. EF is intended to support services that offer tightly-bounded loss, delay, and delay jitter.
2. 迅速な転送（EF）PHB [RFC3246] [RFC3248]は、パケットが明確に定義された最小出発率を保証することを保証します。EFは、緊密に縛られた損失、遅延、遅延ジッターを提供するサービスをサポートすることを目的としています。
3. The Assured Forwarding (AF) PHB group [RFC2597] offers different levels of forwarding assurance for each aggregated flow of packets. Each AF group is independently allocated forwarding resources. Packets are marked with one of three drop precedences; those with the highest drop precedence are dropped with lower probability than those marked with the lowest drop precedence. DSCPs are recommended for four independent AF groups, although a DS domain can have more or fewer AF groups.
3. Assured Forwarding（AF）PHB Group [RFC2597]は、パケットの集合フローごとにさまざまなレベルの転送保証を提供します。各AFグループは、独立して転送リソースを割り当てられています。パケットには、3つのドロップの優先順位のいずれかがマークされています。低下の優先順位が最も高い人は、低下の優先順位が最も低い人よりも低い確率で低下します。DS DSCPは、4つの独立したAFグループに推奨されますが、DSドメインにはAFグループが多いか少ない場合があります。
Ongoing work in the IETF is addressing ways to support Intserv with Diffserv. There is some belief (e.g., as expressed in [RFC2990]) that such an approach will allow individual flows to receive service guarantees and scale to the global Internet.
IETFで進行中の作業は、diffservを使用してIntServをサポートする方法に取り組んでいます。このようなアプローチにより、個々のフローがサービス保証とグローバルインターネットへのスケールを受け取ることができるといういくつかの信念（例えば、[RFC2990]で表現されているように）があります。
The QoS guarantees that can be offered by the IP layer are a product of two factors:
IPレイヤーで提供できるQoS保証は、2つの要因の積です。
1. the concatenation of the QoS guarantees offered by the subnets along the path of a flow. This implies that a subnet may wish to offer multiple services (with different QoS guarantees) to the IP layer, which can then determine which flows use which subnet service. To put it another way, forwarding behavior in the subnet needs to be "clued" by the forwarding behavior (service or PHB) at the IP layer, and
1. 流れの経路に沿ったサブネットによって提供されるQoS保証の連結。これは、サブネットがIPレイヤーに複数のサービス（異なるQoS保証付き）を提供することを望んでいることを意味し、それがどのフローがどのサブネットサービスを使用するかを決定できます。別の言い方をすれば、サブネットでの転送動作は、IPレイヤーで転送動作（サービスまたはPHB）によって「クロー」される必要があります。
2. the operation of a set of cooperating mechanisms, such as bandwidth reservation and admission control, policy management, traffic classification, traffic conditioning (marking, policing and/or shaping), selective discard, queuing, and scheduling. Note that support for QoS in subnets may require similar mechanisms, especially when these subnets are general topology subnets (e.g., ATM, frame relay, or MPLS) or shared media subnets.
2. 帯域幅の予約と入場管理、ポリシー管理、トラフィック分類、交通条件付け（マーキング、ポリシングおよび/またはシェーピング）、選択的破棄、キューイング、スケジューリングなど、一連の協力メカニズムの操作。サブネットでのQoSのサポートには、特にこれらのサブネットが一般的なトポロジサブネット（ATM、フレームリレー、またはMPLSなど）または共有メディアサブネットである場合、同様のメカニズムが必要になる場合があることに注意してください。
Many subnetwork designers face inherent tradeoffs between delay, throughput, reliability, and cost. Other subnetworks have parameters that manage bandwidth, internal connection state, and the like. Therefore, the following subnetwork capabilities may be desirable, although some might be trivial or moot if the subnet is a dedicated point-to-point link.
多くのサブネットワークデザイナーは、遅延、スループット、信頼性、コストの間の固有のトレードオフに直面しています。他のサブネットワークには、帯域幅、内部接続状態などを管理するパラメーターがあります。したがって、サブネットが専用のポイントツーポイントリンクである場合、一部のサブネットワーク機能が望ましい場合がありますが、一部は些細なものまたは論争です。
1. The subnetwork should have the ability to reserve bandwidth for a connection or flow and schedule packets accordingly.
1. サブネットワークには、接続またはフローパケットの帯域幅を予約し、それに応じてパケットをスケジュールする機能を備えている必要があります。
2. Bandwidth reservations should be based on a one- or two-token bucket model, depending on whether the service is intended to support constant-rate or bursty traffic.
2. 帯域幅の予約は、サービスが一定のレートまたは破裂したトラフィックをサポートすることを意図しているかどうかに応じて、1つまたは2トークンのバケットモデルに基づいている必要があります。
3. If a connection or flow does not use its reserved bandwidth at a given time, the unused bandwidth should be available for other flows.
3. 接続またはフローが特定の時間に予約された帯域幅を使用しない場合、未使用の帯域幅は他のフローで使用できるはずです。
4. Packets in excess of a connection or flow's agreed rate should be forwarded as best-effort or discarded, depending on the service offered by the subnet to the IP layer.
4. 接続またはフローの合意されたレートを超えるパケットは、サブネットがIPレイヤーに提供するサービスに応じて、ベストエフォルトまたは破棄として転送する必要があります。
5. If a subnet contains error control mechanisms (retransmission and/or FEC), it should be possible for the IP layer to influence the inherent tradeoffs between uncorrected errors, packet losses, and delay. These capabilities at the subnet/IP layer service boundary correspond to selection of more or less error control and/or to selection of particular error control mechanisms within the subnetwork.
5. サブネットにエラー制御メカニズム（再送信および/またはFEC）が含まれている場合、IPレイヤーが修正されていないエラー、パケット損失、遅延の間の固有のトレードオフに影響を与える可能性があります。サブネット/IPレイヤーサービスの境界でのこれらの機能は、多かれ少なかれエラー制御の選択および/またはサブネットワーク内の特定のエラー制御メカニズムの選択に対応しています。
6. The subnet layer should know, and be able to inform the IP layer, how much fixed delay and delay jitter it offers for a flow or connection. If the Intserv model is used, the delay jitter component may be best expressed in terms of the TSpec/RSpec model described in [RFC2212].
6. サブネットレイヤーは、Flowまたは接続に対して提供される固定遅延と遅延ジッタを知る必要があります。INTSERVモデルを使用すると、[RFC2212]で説明されているTSPEC/RSPECモデルの観点から、遅延ジッターコンポーネントが最適に表現される場合があります。
7. Support of the Diffserv class selectors [RFC2474] suggests that the subnet might consider mechanisms that support priorities.
7. DiffServクラスセレクター[RFC2474]のサポートは、サブネットが優先順位をサポートするメカニズムを考慮する可能性があることを示唆しています。
Subnetwork designers should be aware of the tradeoffs between fairness and efficiency inherent in many transmission scheduling algorithms. For example, many local area networks use contention protocols to resolve access to a shared transmission channel. These protocols represent overhead. While limiting the amount of data that a subnet node may transmit per contention cycle helps assure timely access to the channel for each subnet node, it also increases contention overhead per unit of data sent.
サブネットワークの設計者は、多くの送信スケジューリングアルゴリズムに内在する公平性と効率性のトレードオフを認識する必要があります。たとえば、多くのローカルエリアネットワークは、競合プロトコルを使用して、共有送信チャネルへのアクセスを解決します。これらのプロトコルはオーバーヘッドを表します。サブネットノードが競合サイクルごとに送信できるデータの量を制限すると、各サブネットノードのチャネルへのタイムリーなアクセスが保証されますが、送信されたデータの単位ごとの競合間のオーバーヘッドも増加します。
In some mobile radio networks, capacity is limited by interference, which in turn depends on average transmitter power. Some receivers may require considerably more transmitter power (generating more interference and consuming more channel capacity) than others.
一部のモバイル無線ネットワークでは、容量は干渉によって制限され、干渉は平均的な送信機の電力に依存します。一部のレシーバーは、他のレシーバーよりもかなり多くのトランスミッター電力（より多くの干渉を生成し、より多くのチャネル容量を消費する）を必要とする場合があります。
In each case, the scheduling algorithm designer must balance competing objectives: providing a fair share of capacity to each subnet node while maximizing the total capacity of the network. One approach for balancing performance and fairness is outlined in [ES00].
いずれの場合も、スケジューリングアルゴリズム設計者は、競合する目標のバランスをとる必要があります。ネットワークの総容量を最大化しながら、各サブネットノードにかなりの容量を提供することです。パフォーマンスと公平性のバランスをとるための1つのアプローチは、[ES00]で概説されています。
The TCP sender bases its retransmission timeout (RTO) on measurements of the round trip delay experienced by previous packets. This allows TCP to adapt automatically to the very wide range of delays found on the Internet. The recommended algorithms are described in [RFC2988]. Evaluations of TCP's retransmission timer can be found in [AP99] and [LS00].
TCP送信者は、以前のパケットが経験した往復遅延の測定に再送信タイムアウト（RTO）を基づいています。これにより、TCPはインターネット上で見つかった非常に幅広い遅延に自動的に適応することができます。推奨されるアルゴリズムは[RFC2988]で説明されています。TCPの再送信タイマーの評価は、[AP99]および[LS00]に記載されています。
These algorithms model the delay along an Internet path as a normally-distributed random variable with a slowly-varying mean and standard deviation. TCP estimates these two parameters by exponentially smoothing individual delay measurements, and it sets the RTO to the estimated mean delay plus some fixed number of standard deviations. (The algorithm actually uses mean deviation as an approximation to standard deviation, because it is easier to compute.)
これらのアルゴリズムは、ゆっくりと変化する平均および標準偏差を備えた通常分散したランダム変数として、インターネットパスに沿った遅延をモデル化します。TCPは、個々の遅延測定値を指数関数的にスムーズ化することにより、これら2つのパラメーターを推定し、RTOを推定平均遅延に加えて標準偏差のいくつかの固定数に設定します。（アルゴリズムは、実際には、計算が容易であるため、標準偏差の近似として平均偏差を使用します。）
The goal is to compute an RTO that is small enough to detect and recover from packet losses while minimizing unnecessary ("spurious") retransmissions when packets are unexpectedly delayed but not lost. Although these goals conflict, the algorithm works well when the delay variance along the Internet path is low, or the packet loss rate is low.
目標は、パケットが予期せず遅延しているが失われていないときに不必要な（「偽物」）再送信を最小限に抑えながら、パケットの損失を検出して回復するのに十分小さいRTOを計算することです。これらの目標は矛盾しますが、インターネットパスに沿った遅延分散が低い場合、またはパケット損失率が低い場合、アルゴリズムはうまく機能します。
If the path delay variance is high, TCP sets an RTO that is much larger than the mean of the measured delays. If the packet loss rate is low, the large RTO is of little consequence, as timeouts occur only rarely. Conversely, if the path delay variance is low, then TCP recovers quickly from lost packets; again, the algorithm works well. However, when delay variance and the packet loss rate are both high, these algorithms perform poorly, especially when the mean delay is also high.
パス遅延分散が高い場合、TCPは測定された遅延の平均よりもはるかに大きいRTOを設定します。パケットの損失率が低い場合、タイムアウトはめったに発生しないため、大きなRTOはほとんど影響しません。逆に、パス遅延分散が低い場合、TCPは失われたパケットから迅速に回復します。繰り返しますが、アルゴリズムはうまく機能します。ただし、遅延の分散とパケット損失率が両方が高い場合、これらのアルゴリズムは、特に平均遅延も高い場合、パフォーマンスが低くなります。
Because TCP uses returning acknowledgments as a "clock" to time the transmission of additional data, excessively high delays (even if the delay variance is low) also affect TCP's ability to fully utilize a high-speed transmission pipe. It also slows the recovery of lost packets, even when delay variance is small.
TCPは、追加データの送信をタイミングするために「クロック」として謝辞を「クロック」として使用するため、高速伝送パイプを完全に利用するTCPの能力にも影響を与えます（遅延分散が低い場合でも）。また、遅延の分散が小さい場合でも、失われたパケットの回復を遅くします。
Subnetwork designers should therefore minimize all three parameters (delay, delay variance, and packet loss) as much as possible.
したがって、サブネットワークの設計者は、できるだけ3つのパラメーター（遅延、遅延分散、パケット損失）を最小限に抑える必要があります。
In many subnetworks, these parameters are inherently in conflict. For example, on a mobile radio channel, the subnetwork designer can use retransmission (ARQ) and/or forward error correction (FEC) to trade off delay, delay variance, and packet loss in an effort to improve TCP performance. While ARQ increases delay variance, FEC does not. However, FEC (especially when combined with interleaving) often increases mean delay, even on good channels where ARQ retransmissions are not needed and ARQ would not increase either the delay or the delay variance.
多くのサブネットワークでは、これらのパラメーターは本質的に競合しています。たとえば、モバイルラジオチャネルでは、サブネットワーク設計者は、再送信（ARQ）および/またはフォワードエラー補正（FEC）を使用して、TCPパフォーマンスを改善するために遅延、遅延分散、パケット損失をトレードオフすることができます。ARQは遅延分散を増加させますが、FECは増加しません。ただし、FEC（特にインターリーブと組み合わせた場合）は、ARQの再送信が不要であり、ARQが遅延または遅延の分散を増加させない良いチャネルでさえ、平均遅延を増加させることがよくあります。
The tradeoffs among these error control mechanisms and their interactions with TCP can be quite complex, and are the subject of much ongoing research. We therefore recommend that subnetwork designers provide as much flexibility as possible in the implementation of these mechanisms, and provide access to them as discussed above in the section on Quality of Service.
これらのエラー制御メカニズムとTCPとの相互作用間のトレードオフは非常に複雑であり、多くの進行中の研究の対象です。したがって、サブネットワークの設計者は、これらのメカニズムの実装にできるだけ多くの柔軟性を提供し、サービス品質に関するセクションで上記のようにそれらにアクセスできるようにすることをお勧めします。
Some subnetworks may provide asymmetric bandwidth (or may cause TCP packet flows to experience asymmetry in the capacity) and the Internet protocol suite will generally still work fine. However, there is a case when such a scenario reduces TCP performance. Since TCP data segments are "clocked" out by returning acknowledgments, TCP senders are limited by the rate at which ACKs can be returned [BPK98]. Therefore, when the ratio of the available capacity of the Internet path carrying the data to the bandwidth of the return path of the acknowledgments is too large, the slow return of the ACKs directly impacts performance. Since ACKs are generally smaller than data segments, TCP can tolerate some asymmetry, but as a general rule, designers of subnetworks should be aware that subnetworks with significant asymmetry can result in reduced performance, unless issues are taken to mitigate this [RFC3449].
一部のサブネットワークは、非対称の帯域幅を提供する場合があり（またはTCPパケットフローが容量の非対称性を発生させる場合があります）、インターネットプロトコルスイートは通常、それでも正常に機能します。ただし、このようなシナリオがTCPパフォーマンスを低下させる場合があります。TCPデータセグメントは謝辞を返すことにより「クロック」されるため、TCP送信者はACKを返すことができる速度によって制限されます[BPK98]。したがって、データを謝辞のリターンパスの帯域幅に運ぶインターネットパスの利用可能な容量の比率が大きすぎる場合、ACKの遅いリターンはパフォーマンスに直接影響します。ACKは一般にデータセグメントよりも小さいため、TCPは何らかの非対称性に耐えることができますが、一般的なルールとして、サブネットワークの設計者は、この[RFC3449]を軽減するために問題が発生しない限り、有意な非対称性を持つサブネットワークがパフォーマンスを低下させる可能性があることを認識する必要があります。
Several strategies have been identified for reducing the impact of asymmetry of the network path between two TCP end hosts, e.g., [RFC3449]. These techniques attempt to reduce the number of ACKs transmitted over the return path (low bandwidth channel) by changes at the end host(s), and/or by modification of subnetwork packet forwarding. While these solutions may mitigate the performance issues caused by asymmetric subnetworks, they do have associated cost and may have other implications. A fuller discussion of strategies and their implications is provided in [RFC3449].
2つのTCPエンドホスト間のネットワークパスの非対称性の影響を減らすためのいくつかの戦略が特定されています[RFC3449]。これらの手法は、エンドホストの変更、および/またはサブネットワークパケット転送の変更により、リターンパス（低帯域幅チャネル）に送信されるACKの数を減らしようとします。これらのソリューションは、非対称サブネットワークによって引き起こされるパフォーマンスの問題を軽減する可能性がありますが、関連するコストがあり、他の意味がある場合があります。戦略とその意味についてのより完全な議論は、[RFC3449]で提供されています。
Many subnets include multiple links with varying traffic demands and possibly different transmission speeds. At each link there must be a queuing system, including buffering, scheduling, and a capability to discard excess subnet packets. These queues may also be part of a subnet flow control or congestion control scheme.
多くのサブネットには、さまざまなトラフィック需要とおそらく異なる伝送速度を持つ複数のリンクが含まれています。各リンクには、バッファリング、スケジューリング、過剰なサブネットパケットを破棄する機能など、キューイングシステムが必要です。これらのキューは、サブネットフロー制御または輻輳制御スキームの一部でもあります。
For the purpose of this discussion, we talk about packets without regard to whether they refer to a complete IP packet or a subnetwork frame. At each queue, a packet experiences a delay that depends on competing traffic and the scheduling discipline, and is subjected to a local discarding policy.
この議論の目的のために、完全なIPパケットまたはサブネットワークフレームを参照するかどうかに関係なく、パケットについて説明します。各キューで、パケットは、競合するトラフィックとスケジューリングの規律に依存する遅延を経験し、地元の廃棄ポリシーにさらされます。
Some subnets may have flow or congestion control mechanisms in addition to packet dropping. Such mechanisms can operate on components in the subnet layer, such as schedulers, shapers, or discarders, and can affect the operation of IP forwarders at the edges of the subnet. However, with the exception of Explicit Congestion Notification [RFC3168] (discussed below), IP has no way to pass explicit congestion or flow control signals to TCP.
一部のサブネットには、パケットドロップに加えて、フローまたは混雑制御メカニズムがある場合があります。このようなメカニズムは、スケジューラ、シェイパー、廃棄物などのサブネット層のコンポーネントで動作し、サブネットの端でのIPフォワーダーの動作に影響を与える可能性があります。ただし、明示的な輻輳通知[RFC3168]（以下で説明）を除き、IPには明示的なうっ血またはフロー制御信号をTCPに合格する方法はありません。
TCP traffic, especially aggregated TCP traffic, is bursty. As a result, instantaneous queue depths can vary dramatically, even in nominally stable networks. For optimal performance, packets should be dropped in a controlled fashion, not just when buffer space is unavailable. How much buffer space should be supplied is still a matter of debate, but as a rule of thumb, each node should have enough buffering to hold one link_bandwidth*link_delay product's worth of data for each TCP connection sharing the link.
TCPトラフィック、特に集約されたTCPトラフィックは破裂しています。その結果、名目上安定したネットワークであっても、瞬間的なキューの深さは劇的に変化する可能性があります。最適なパフォーマンスのために、バッファースペースが利用できない場合だけでなく、パケットを制御された方法でドロップする必要があります。バッファスペースの量はまだ議論の問題ですが、経験則として、各ノードには、リンクを共有する各TCP接続の1つのlink_bandwidth*link_delay製品の価値を保持するのに十分なバッファリングが必要です。
This is often difficult to estimate, since it depends on parameters beyond the subnetwork's control or knowledge. Internet nodes generally do not implement admission control policies, and cannot limit the number of TCP connections that use them. In general, it is wise to err in favor of too much buffering rather than too little. It may also be useful for subnets to incorporate mechanisms that measure propagation delays to assist in buffer sizing calculations.
サブネットワークの制御または知識を超えたパラメーターに依存するため、これはしばしば推定することが困難です。インターネットノードは一般に、入場制御ポリシーを実装せず、それらを使用するTCP接続の数を制限することはできません。一般的に、少なすぎるのではなく、あまりにも多くのバッファリングを支持して誤りを犯すことが賢明です。また、サブネットが伝播遅延を測定してバッファーサイジングの計算を支援するメカニズムを組み込むことに役立つ場合があります。
There is a rough consensus in the research community that active queue management is important to improving fairness, link utilization, and throughput [RFC2309]. Although there are questions and concerns about the effectiveness of active queue management (e.g., [MBDL99]), it is widely considered an improvement over tail-drop discard policies.
研究コミュニティでは、公平性、リンク利用、スループット[RFC2309]を改善するには、アクティブキュー管理が重要であるという大まかなコンセンサスがあります。アクティブなキュー管理の有効性について疑問と懸念がありますが（例：[MBDL99]）、それはテールドロップ廃棄ポリシーよりも改善されていると広く考えられています。
One form of active queue management is the Random Early Detection (RED) algorithm [RED93], a family of related algorithms. In one version of RED, an exponentially-weighted moving average of the queue depth is maintained:
アクティブキュー管理の1つの形式は、関連するアルゴリズムのファミリーであるランダムアーリー検出（RED）アルゴリズム[RED93]です。Redの1つのバージョンでは、キューの深さの指数関数的に加重された移動平均が維持されます。
When this average queue depth is between a maximum threshold max_th and a minimum threshold min_th, the probability of packets that are dropped is proportional to the amount by which the average queue depth exceeds min_th.
この平均キューの深さが最大しきい値max_thと最小しきい値min_thの間にある場合、ドロップされるパケットの確率は、平均キューの深さがmin_thを超える量に比例します。
When this average queue depth is equal to max_th, the drop probability is equal to a configurable parameter max_p.
この平均キューの深さがmax_thに等しい場合、ドロップ確率は構成可能なパラメーターmax_pに等しくなります。
When this average queue depth is greater than max_th, packets are always dropped.
この平均キューの深さがmax_thよりも大きい場合、パケットは常に削除されます。
Numerous variants on RED appear in the literature, and there are other active queue management algorithms which claim various advantages over RED [GM02].
文献には赤の多数のバリエーションが現れ、他のアクティブなキュー管理アルゴリズムがあり、赤に対するさまざまな利点を主張しています[GM02]。
With an active queue management algorithm, dropped packets become a feedback signal to trigger more appropriate congestion behavior by the TCPs in the end hosts. Randomization of dropping tends to break up the observed tendency of TCP windows belonging to different TCP connections to become synchronized by correlated drops, and it also imposes a degree of fairness on those connections that implement TCP congestion avoidance properly. Another important property of active queue management algorithms is that they attempt to keep average queue depths short while accommodating large short-term bursts.
アクティブなキュー管理アルゴリズムを使用すると、ドロップされたパケットがフィードバック信号になり、最終ホストのTCPによるより適切な輻輳動作をトリガーします。ドロップのランダム化は、異なるTCP接続に属するTCPウィンドウの観察された傾向を分解する傾向があり、相関液滴によって同期されるようになり、TCPの混雑回避を適切に実装する接続にある程度の公平性を課します。アクティブキュー管理アルゴリズムのもう1つの重要な特性は、大規模な短期バーストに対応しながら、平均キューの深さを短くしようとすることです。
Since TCP neither knows nor cares whether congestive packet loss occurs at the IP layer or in a subnet, it may be advisable for subnets that perform queuing and discarding to consider implementing some form of active queue management. This is especially true if large aggregates of TCP connections are likely to share the same queue. However, active queue management may be less effective in the case of many queues carrying smaller aggregates of TCP connections, e.g., in an ATM switch that implements per-VC queuing.
TCPは、うっ血性パケットの損失がIPレイヤーで発生するかサブネットで発生するかを知らないことも気にしないため、キューイングと破棄を実行するサブネットが何らかの形のアクティブキュー管理の実装を検討することをお勧めします。これは、TCP接続の大きな集合体が同じキューを共有する可能性が高い場合に特に当てはまります。ただし、TCP接続の小さな集合体を運ぶ多くのキューの場合、たとえば、VCごとのキューイングを実装するATMスイッチでアクティブキュー管理の効果が低下する可能性があります。
Note that the performance of active queue management algorithms is highly sensitive to settings of configurable parameters, and also to factors such as RTT [MBB00] [FB00].
アクティブキュー管理アルゴリズムのパフォーマンスは、構成可能なパラメーターの設定、およびRTT [MBB00] [FB00]などの要因にも非常に敏感であることに注意してください。
Some subnets, most notably ATM, perform segmentation and reassembly at the subnetwork edges. Care should be taken here in designing discard policies. If the subnet discards a fragment of an IP packet, then the remaining fragments become an unproductive load on the subnet that can markedly degrade end-to-end performance [RF95]. Subnetworks should therefore attempt to discard these extra fragments whenever one of them must be discarded. If the IP packet has already been partially forwarded when discarding becomes necessary, then every remaining fragment except the one marking the end of the IP packet should also be discarded. For ATM subnets, this specifically means using Early Packet Discard and Partial Packet Discard [ATMFTM].
一部のサブネット、特にATMは、サブネットワークのエッジでセグメンテーションと再組み立てを実行します。ここでは、廃棄ポリシーの設計に注意する必要があります。サブネットがIPパケットのフラグメントを破棄すると、残りのフラグメントはサブネットの非生産的な負荷になり、エンドツーエンドのパフォーマンスを著しく分解できます[RF95]。したがって、サブネットワークは、それらの1つを破棄する必要がある場合はいつでも、これらの余分な断片を破棄しようとする必要があります。破棄が必要になるとIPパケットが既に部分的に転送されている場合、IPパケットの端をマークするものを除くすべての残りのフラグメントも破棄する必要があります。ATMサブネットの場合、これは特に早期のパケット廃棄と部分的なパケット廃棄[ATMFTM]を使用することを意味します。
Some subnets include flow control mechanisms that effectively require that the rate of traffic flows be shaped upon entry to the subnet. One example of such a subnet mechanism is in the ATM Available Bit rate (ABR) service category [ATMFTM]. Such flow control mechanisms have the effect of making the subnet nearly lossless by pushing congestion into the IP routers at the edges of the subnet. In such a case, adequate buffering and discard policies are needed in these routers to deal with a subnet that appears to have varying bandwidth. Whether there is a benefit in this kind of flow control is controversial; there are numerous simulation and analytical studies that go both ways. It appears that some of the issues leading to such different results include sensitivity to ABR parameters, use of binary rather than explicit rate feedback, use (or not) of per-VC queuing, and the specific ATM switch algorithms selected for the study. Anecdotally, some large networks that used IP over ABR to carry TCP traffic have claimed it to be successful, but have published no results.
一部のサブネットには、サブネットへの入力時にトラフィックフローの速度を効果的に必要とするフロー制御メカニズムが含まれています。このようなサブネットメカニズムの1つの例は、ATM利用可能ビットレート（ABR）サービスカテゴリ[ATMFTM]です。このようなフロー制御メカニズムは、サブネットのエッジのIPルーターに輻輳を押し込むことにより、サブネットをほぼロスレスにする効果があります。そのような場合、これらのルーターでは、帯域幅が変化すると思われるサブネットを扱うために、適切なバッファリングと破棄ポリシーが必要です。この種のフロー制御に利益があるかどうかは議論の余地があります。両方の方法で進む多くのシミュレーションと分析研究があります。このような異なる結果につながる問題のいくつかには、ABRパラメーターへの感度、明示的なレートフィードバックではなくバイナリの使用、VCごとのキューイングの使用（またはそうでない）、および研究用に選択された特定のATMスイッチアルゴリズムが含まれているようです。逸話的に、TCPトラフィックを運ぶためにABRを使用したいくつかの大規模なネットワークは、それが成功したと主張していますが、結果は発表していません。
Another possible approach to flow control in the subnet would be to work with TCP Explicit Congestion Notification (ECN) semantics [RFC3168] through utilizing explicit congestion indicators in subnet frames. Routers at the edges of the subnet, rather than shaping, would set the explicit congestion bit in those IP packets that are received in subnet frames that have an ECN indication. Nodes in the subnet would need to implement an active queue management protocol that marks subnet frames instead of dropping them.
サブネットでのフロー制御への別の可能なアプローチは、サブネットフレームで明示的な輻輳インジケーターを利用して、TCP明示的なうっ血通知（ECN）セマンティクス[RFC3168]を使用することです。サブネットのエッジのルーターは、シェーピングではなく、Subnetフレームで受信されたIPパケットに明示的なうっ血ビットを設定します。サブネットのノードは、ドロップする代わりにサブネットフレームをマークするアクティブなキュー管理プロトコルを実装する必要があります。
ECN is currently a proposed standard, but it is not yet widely deployed.
現在、ECNは提案されている標準ですが、まだ広く展開されていません。
Application data compression is a function that can usually be omitted in the subnetwork. The endpoints typically have more CPU and memory resources to run a compression algorithm and a better understanding of what is being compressed. End-to-end compression benefits every network element in the path, while subnetwork-layer compression, by definition, benefits only a single subnetwork.
アプリケーションデータ圧縮は、通常サブネットワークで省略できる関数です。エンドポイントには、通常、圧縮アルゴリズムを実行するためのCPUおよびメモリリソースが多くなり、圧縮されているもののより良い理解があります。エンドツーエンドの圧縮は、パス内のすべてのネットワーク要素に役立ちますが、定義上、サブネットワーク層圧縮は単一のサブネットワークのみに利益をもたらします。
Data presented to the subnetwork layer may already be in a compressed format (e.g., a JPEG file), compressed at the application layer (e.g., the optional "gzip", "compress", and "deflate" compression in HTTP/1.1 [RFC2616]), or compressed at the IP layer (the IP Payload Compression Protocol [RFC3173] supports DEFLATE [RFC2394] and LZS [RFC2395]). Compression at the subnetwork edges is of no benefit for any of these cases.
サブネットワークレイヤーに提示されたデータは、既に圧縮形式（jpegファイルなど）で、アプリケーション層（例：オプションの「gzip」、「圧縮」、およびhttp/1.1 [RFC2616の「デフレート」圧縮」にある場合があります。]、またはIPレイヤーで圧縮されます（IPペイロード圧縮プロトコル[RFC3173]は、DEFLATE [RFC2394]およびLZS [RFC2395]をサポートします）。サブネットワークのエッジでの圧縮は、これらのケースのいずれにおいても有益ではありません。
The subnetwork may also process data that has been encrypted by the application (OpenPGP [RFC2440] or S/MIME [RFC2633]), just above TCP (SSL, TLS [RFC2246]), or just above IP (IPsec ESP [RFC2406]).
サブネットワークは、アプリケーションによって暗号化されたデータ（OpenPGP [RFC2440]またはS/MIME [RFC2633]）、TCP（SSL、TLS [RFC2246]）、またはIP（IPSEC ESP [RFC2406]）を超えるデータを処理することもできます。。
Ciphers generate high-entropy bit streams lacking any patterns that can be exploited by a compression algorithm.
暗号は、圧縮アルゴリズムによって悪用される可能性のあるパターンを欠く高エントロピービットストリームを生成します。
However, much data is still transmitted uncompressed over the Internet, so subnetwork compression may be beneficial. Any subnetwork compression algorithm must not expand uncompressible data, e.g., data that has already been compressed or encrypted.
ただし、多くのデータはインターネットを介して非圧縮されているため、サブネットワークの圧縮が有益である可能性があります。サブネットワーク圧縮アルゴリズムは、圧縮性のないデータを拡張してはなりません。たとえば、すでに圧縮または暗号化されているデータ。
We make a strong recommendation that subnetworks operating at low speed or with small MTUs compress IP and transport-level headers (TCP and UDP) using several header compression schemes developed within the IETF [RFC3150]. An uncompressed 40-byte TCP/IP header takes about 33 milliseconds to send at 9600 bps. "VJ" TCP/IP header compression [RFC1144] compresses most headers to 3-5 bytes, reducing transmission time to several milliseconds on dialup modem links. This is especially beneficial for small, latency-sensitive packets in interactive sessions.
IETF [RFC3150]内で開発されたいくつかのヘッダー圧縮スキームを使用して、低速または小型MTUコンプレスIPおよびトランスポートレベルのヘッダー（TCPおよびUDP）を使用して動作するサブネットワークを強く推奨しています。圧縮されていない40バイトTCP/IPヘッダーは、9600 bpsで送信するのに約33ミリ秒かかります。「VJ」TCP/IPヘッダー圧縮[RFC1144]は、ほとんどのヘッダーを3〜5バイトに圧縮し、Dialup Modemリンクで伝送時間を数ミリ秒に短縮します。これは、インタラクティブセッションの小規模で遅延に敏感なパケットにとって特に有益です。
Similarly, RTP compression schemes, such as CRTP [RFC2508] and ROHC [RFC3095], compress most IP/UDP/RTP headers to 1-4 bytes. The resulting savings are especially significant when audio packets are kept small to minimize store-and-forward latency.
同様に、CRTP [RFC2508]やROHC [RFC3095]などのRTP圧縮スキームは、ほとんどのIP/UDP/RTPヘッダーを1-4バイトに圧縮します。結果として生じる節約は、ストアとフォワードのレイテンシを最小限に抑えるためにオーディオパケットを小さく保つ場合に特に重要です。
Designers should consider the effect of the subnetwork error rate on the performance of header compression. TCP ordinarily recovers from lost packets by retransmitting only those packets that were actually lost; packets arriving correctly after a packet loss are kept on a resequencing queue and do not need to be retransmitted. In VJ TCP/IP [RFC1144] header compression, however, the receiver cannot explicitly notify a sender of data corruption and subsequent loss of synchronization between compressor and decompressor. It relies instead on TCP retransmission to re-synchronize the decompressor. After a packet is lost, the decompressor must discard every subsequent packet, even if the subnetwork makes no further errors, until the sending TCP retransmits to re-synchronize the decompressor. This effect can substantially magnify the effect of subnetwork packet losses if the sending TCP window is large, as it will often be on a path with a large bandwidth*delay product [LRKOJ99].
設計者は、ヘッダー圧縮のパフォーマンスに対するサブネットワークエラー率の影響を考慮する必要があります。TCPは、実際に失われたパケットのみを再送信することにより、紛失したパケットから通常回復します。パケットの損失が再配置された後に正しく到着するパケットは、再送信する必要はありません。ただし、VJ TCP/IP [RFC1144]ヘッダー圧縮では、受信者は、コンプレッサーと減圧装置間のデータ腐敗とその後の同期の喪失を送信者に明示的に通知することはできません。代わりに、減圧剤を再同期させるためのTCPの再送信に依存しています。パケットが失われた後、減圧剤が減圧器を再同期させるために送信されるTCPが再導き合うまで、サブネットワークがそれ以上エラーを犯さない場合でも、減圧器はその後のすべてのパケットを破棄する必要があります。この効果は、送信するTCPウィンドウが大きい場合、サブネットワークパケット損失の効果を大幅に拡大することができます。
Alternate header compression schemes, such as those described in [RFC2507], include an explicit request for retransmission of an uncompressed packet to allow decompressor resynchronization without waiting for a TCP retransmission. However, these schemes are not yet in widespread use.
[RFC2507]に記載されているような代替ヘッダー圧縮スキームには、非圧縮パケットの再送信の明示的な要求が含まれており、TCPの再送信を待たずに減圧器の再同期を可能にします。ただし、これらのスキームはまだ広範囲に使用されていません。
Both TCP header compression schemes do not compress widely-used TCP options such as selective acknowledgements (SACK). Both fail to compress TCP traffic that makes use of explicit congestion notification (ECN). Work is under way in the IETF ROHC WG to address these shortcomings in a ROHC header compression scheme for TCP [RFC3095] [RFC3096].
両方のTCPヘッダー圧縮スキームは、選択的謝辞（SACK）などの広く使用されているTCPオプションを圧縮しません。どちらも、明示的な混雑通知（ECN）を使用するTCPトラフィックを圧縮できません。IETF ROHC WGでは、TCP [RFC3095] [RFC3096]のROHCヘッダー圧縮スキームでこれらの欠点に対処するための作業が進行中です。
The subnetwork error rate also is important for RTP header compression. CRTP uses delta encoding, so a packet loss on the link causes uncertainty about the subsequent packets, which often must be discarded until the decompressor has notified the compressor and the compressor has sent re-synchronizing information. This typically takes slightly more than the end-to-end path round-trip time. For links that combine significant error rates with latencies that require multiple packets to be in flight at a time, this leads to significant error propagation, i.e., subsequent losses caused by an initial loss.
サブネットワークエラー率もRTPヘッダー圧縮に重要です。CRTPはデルタエンコーディングを使用するため、リンクのパケット損失は、後続のパケットに関する不確実性を引き起こします。これは、減圧装置がコンプレッサーに通知し、コンプレッサーが再同期化情報を送信するまで廃棄する必要があることがよくあります。これは通常、エンドツーエンドのパスの往復時間よりわずかに多くかかります。重要なエラー率と、一度に飛行中の複数のパケットを必要とするレイテンシーを組み合わせたリンクの場合、これは大幅なエラー伝播、つまり初期の損失によって引き起こされるその後の損失につながります。
For links that are both high-latency (multiple packets in flight from a typical RTP stream) and error-prone, RTP ROHC provides a more robust way of RTP header compression, at a cost of higher complexity at the compressor and decompressor. For example, within a talk spurt, only extended losses of (depending on the mode chosen) 12-64 packets typically cause error propagation.
RTP ROHCは、高遅延（典型的なRTPストリームからの飛行中の複数のパケット）とエラーが発生しやすいリンクの場合、コンプレッサーと分解器でより高い複雑さを犠牲にして、より堅牢なRTPヘッダー圧縮の方法を提供します。たとえば、講演では、（選択したモードに応じて）12-64パケットの損失のみが延長されただけで、エラーの伝播を引き起こします。
The Internet architecture does not guarantee that packets will arrive in the same order in which they were originally transmitted; transport protocols like TCP must take this into account.
インターネットアーキテクチャは、パケットが元々送信されたのと同じ順序で到着することを保証するものではありません。TCPのような輸送プロトコルは、これを考慮する必要があります。
However, reordering does come at a cost with TCP as it is currently defined. Because TCP returns a cumulative acknowledgment (ACK) indicating the last in-order segment that has arrived, out-of-order segments cause a TCP receiver to transmit a duplicate acknowledgment. When the TCP sender notices three duplicate acknowledgments, it assumes that a segment was dropped by the network and uses the fast retransmit algorithm [Jac90] [RFC2581] to resend the segment. In addition, the congestion window is reduced by half, effectively halving TCP's sending rate. If a subnetwork reorders segments significantly such that three duplicate ACKs are generated, the TCP sender needlessly reduces the congestion window and performance suffers.
ただし、現在定義されているため、並べ替えはTCPで費用がかかります。TCPは、到着した最後の注文セグメントを示す累積承認（ACK）を返すため、オーバーアウトセグメントにより、TCPレシーバーが重複した確認を送信します。TCP送信者が3つの重複謝辞に通知すると、セグメントがネットワークによって削除され、高速再送信アルゴリズム[JAC90] [RFC2581]を使用してセグメントを再送信すると想定しています。さらに、輻輳ウィンドウは半分に減少し、TCPの送信率を効果的に半分にします。サブネットワークが3つの重複したAcksが生成されるようにセグメントを大幅に再配置すると、TCP送信者は不必要に輻輳ウィンドウを減らし、パフォーマンスが低下します。
Packet reordering frequently occurs in parts of the Internet, and it seems to be difficult or impossible to eliminate [BPS99]. For this reason, research on improving TCP's behavior in the face of packet reordering [LK00] [BA02] has begun.
パケットの並べ替えは、インターネットの一部で頻繁に発生し、排除することは困難または不可能であるようです[BPS99]。このため、パケットの再注文[LK00] [BA02]に直面したTCPの行動の改善に関する研究が始まりました。
[BPS99] cites reasons why it may even be undesirable to eliminate reordering. There are situations where average packet latency can be reduced, link efficiency can be increased, and/or reliability can be improved if reordering is permitted. Examples include certain high speed switches within the Internet backbone and the parallel links used over many Internet paths for load splitting and redundancy.
[BPS99]は、並べ替えを排除することさえ望ましくない理由を引用しています。平均パケットレイテンシを減らし、リンクの効率を向上させることができ、並べ替えが許可されれば信頼性を向上させることができる状況があります。例には、インターネットバックボーン内の特定の高速スイッチと、ロード分割と冗長性のために多くのインターネットパスで使用される並列リンクが含まれます。
This suggests that subnetwork implementers should try to avoid packet reordering whenever possible, but not if doing so compromises efficiency, impairs reliability, or increases average packet delay.
これは、サブネットワークの実装者が可能な限りパケットの並べ替えを避けようとする必要があることを示唆していますが、効率を損なう、信頼性を損なう、または平均パケット遅延を増加させる場合はそうではありません。
Note that every header compression scheme currently standardized for the Internet requires in-order packet delivery on the link between compressor and decompressor. PPP is frequently used to carry compressed TCP/IP packets; since it was originally designed for point-to-point and dialup links, it is assumed to provide in-order delivery. For this reason, subnetwork implementers who provide PPP interfaces to VPNs and other more complex subnetworks, must also maintain in-order delivery of PPP frames.
現在、インターネット用に標準化されているすべてのヘッダー圧縮スキームには、コンプレッサーと減圧装置間のリンクでの注文のパケット配信が必要であることに注意してください。PPPは、圧縮されたTCP/IPパケットを運ぶために頻繁に使用されます。もともとはポイントツーポイントとダイヤルアップリンク用に設計されていたため、次の配信を提供すると想定されています。このため、VPNおよびその他のより複雑なサブネットワークにPPPインターフェイスを提供するサブネットワークの実装者も、PPPフレームの順序配信を維持する必要があります。
Internet users are increasingly mobile. Not only are many Internet nodes laptop computers, but pocket organizers and mobile embedded systems are also becoming nodes on the Internet. These nodes may connect to many different access points on the Internet over time, and they expect this to be largely transparent to their activities. Except when they are not connected to the Internet at all, and for performance differences when they are connected, they expect that everything will "just work" regardless of their current Internet attachment point or local subnetwork technology.
インターネットユーザーはますますモバイルになっています。多くのインターネットノードがラップトップコンピューターであるだけでなく、ポケットオーガナイザーとモバイル組み込みシステムもインターネット上のノードになりつつあります。これらのノードは、時間の経過とともにインターネット上のさまざまなアクセスポイントに接続する可能性があり、これがアクティビティに対して主に透明であると予想しています。インターネットにまったく接続されていない場合、および接続されているときのパフォーマンスの違いについては、現在のインターネット添付ファイルのポイントやローカルサブネットワークテクノロジーに関係なく、すべてが「ただ機能する」ことを期待しています。
Changing a host's Internet attachment point involves one or more of the following steps.
ホストのインターネットアタッチメントポイントを変更するには、次の手順の1つ以上が含まれます。
First, if use of the local subnetwork is restricted, the user's credentials must be verified and access granted. There are many ways to do this. A trivial example would be an "Internet cafe" that grants physical access to the subnetwork for a fee. Subnetworks may implement technical access controls of their own; one example is IEEE 802.11 Wireless Equivalent Privacy [IEEE80211]. It is common practice for both cellular telephone and Internet service providers (ISPs) to agree to serve one anothers' users; RADIUS [RFC2865] is the standard method for ISPs to exchange authorization information.
まず、ローカルサブネットワークの使用が制限されている場合、ユーザーの資格情報を検証し、アクセスを許可する必要があります。これを行うには多くの方法があります。些細な例は、サブネットワークへの物理的なアクセスを有料で付与する「インターネットカフェ」です。Subnetworksは、独自の技術的アクセス制御を実装する場合があります。1つの例は、IEEE 802.11ワイヤレス同等のプライバシー[IEEE80211]です。携帯電話とインターネットサービスプロバイダー（ISP）の両方が、1人のユーザーのユーザーにサービスを提供することに同意することは一般的な慣行です。RADIUS [RFC2865]は、ISPが認証情報を交換するための標準的な方法です。
Second, the host may have to be reconfigured with IP parameters appropriate for the local subnetwork. This usually includes setting an IP address, default router, and domain name system (DNS) servers.
第二に、ホストは、ローカルサブネットワークに適したIPパラメーターを再構成する必要がある場合があります。これには通常、IPアドレス、デフォルトのルーター、およびドメイン名システム（DNS）サーバーの設定が含まれます。
On multiple-access networks, the Dynamic Host Configuration Protocol (DHCP) [RFC2131] is almost universally used for this purpose. On PPP links, these functions are performed by the IP Control Protocol (IPCP) [RFC1332].
複数のアクセスネットワークでは、動的ホスト構成プロトコル（DHCP）[RFC2131]は、この目的のためにほぼ普遍的に使用されています。PPPリンクでは、これらの関数はIPコントロールプロトコル（IPCP）[RFC1332]によって実行されます。
Third, traffic destined for the mobile host must be routed to its current location. This roaming function is the most common meaning of the term "Internet mobility".
第三に、モバイルホスト向けに運命づけられているトラフィックは、現在の場所にルーティングする必要があります。このローミング機能は、「インターネットモビリティ」という用語の最も一般的な意味です。
Internet mobility can be provided at any of several layers in the Internet protocol stack, and there is ongoing debate as to which is the most appropriate and efficient. Mobility is already a feature of certain application layer protocols; the Post Office Protocol (POP) [RFC1939] and the Internet Message Access Protocol (IMAP) [RFC3501] were created specifically to provide mobility in the receipt of electronic mail.
インターネットのモビリティは、インターネットプロトコルスタックのいくつかのレイヤーのいずれかで提供できます。また、どちらが最も適切で効率的であるかについて継続的な議論があります。モビリティは、すでに特定のアプリケーションレイヤープロトコルの機能です。郵便局プロトコル（POP）[RFC1939]およびインターネットメッセージアクセスプロトコル（IMAP）[RFC3501]は、電子メールの受領でモビリティを提供するために特別に作成されました。
Mobility can also be provided at the IP layer [RFC3344]. This mechanism provides greater transparency, viz., IP addresses that remain fixed as the nodes move, but at the cost of potentially significant network overhead and increased delay because of the sub-optimal network routing and tunneling involved.
モビリティは、IPレイヤー[RFC3344]でも提供できます。このメカニズムは、ノードが移動するにつれて固定されたままであるIPアドレスの透明度を高めますが、潜在的に重要なネットワークオーバーヘッドと遅延が増加し、最適なネットワークルーティングとトンネリングが関与するため、遅延が増加します。
Some subnetworks may provide internal mobility, transparent to IP, as a feature of their own internal routing mechanisms. To the extent that these simplify routing at the IP layer, reduce the need for mechanisms like Mobile IP, or exploit mechanisms unique to the subnetwork, this is generally desirable. This is especially true when the subnetwork covers a relatively small geographic area and the users move rapidly between the attachment points within that area. Examples of internal mobility schemes include Ethernet switching and intra-system handoff in cellular telephony.
一部のサブネットワークは、独自の内部ルーティングメカニズムの特徴として、IPに対して透明な内部モビリティを提供する場合があります。これらがIPレイヤーでのルーティングを簡素化する限り、モバイルIPなどのメカニズムの必要性を減らすか、サブネットワークに固有のメカニズムを活用することで、これは一般的に望ましいです。これは、サブネットワークが比較的小さな地理的領域をカバーし、ユーザーがその領域内のアタッチメントポイント間を急速に移動する場合に特に当てはまります。内部モビリティスキームの例には、携帯電話のイーサネットスイッチングとシステム内ハンドオフが含まれます。
However, if the subnetwork is physically large and connects to other parts of the Internet at multiple geographic points, care should be taken to optimize the wide-area routing of packets between nodes on the external Internet and nodes on the subnet. This is generally done with "nearest exit" routing strategies. Because a given subnetwork may be unaware of the actual physical location of a destination on another subnetwork, it simply routes packets bound for the other subnetwork to the nearest router between the two. This implies some awareness of IP addressing and routing within the subnetwork. The subnetwork may wish to use IP routing internally for wide area routing and restrict subnetwork-specific routing to constrained geographic areas where the effects of suboptimal routing are minimized.
ただし、サブネットワークが物理的に大きく、複数の地理的ポイントでインターネットの他の部分に接続している場合は、外部インターネット上のノード間のパケットの広いエリアルーティングとサブネットのノード間の広範なエリアルーティングを最適化するように注意する必要があります。これは通常、「最も近い出口」ルーティング戦略で行われます。特定のサブネットワークは、別のサブネットワーク上の宛先の実際の物理的位置を知らない可能性があるため、他のサブネットワークにバインドされたパケットを2つの間に最も近いルーターにルーティングするだけです。これは、サブネットワーク内のIPアドレス指定とルーティングに対するある程度の認識を意味します。サブネットワークは、広範囲のルーティングにIPルーティングを内部的に使用し、サブネットワーク固有のルーティングを制約された地理的領域に制限することをお勧めします。
Subnetworks connecting more than two systems must provide their own internal Layer-2 forwarding mechanisms, either implicitly (e.g., broadcast) or explicitly (e.g., switched). Since routing is the major function of the Internet layer, the question naturally arises as to the interaction between routing at the Internet layer and routing in the subnet, and proper division of function between the two.
2つ以上のシステムを接続するサブネットワークは、暗黙的に（たとえば、ブロードキャスト）または明示的に（たとえば、切り替え）、独自の内部レイヤー2転送メカニズムを提供する必要があります。ルーティングはインターネットレイヤーの主要な機能であるため、インターネットレイヤーでのルーティングとサブネットのルーティングと2つの間の適切な分割の間の相互作用に関して、疑問が自然に発生します。
Layer-2 subnetworks can be point-to-point, connecting two systems, or multipoint. Multipoint subnetworks can be broadcast (e.g., shared media or emulated) or non-broadcast. Generally, IP considers multipoint subnetworks as broadcast, with shared-medium Ethernet as the canonical (and historical) example, and point-to-point subnetworks as a degenerate case. Non-broadcast subnetworks may require additional mechanisms, e.g., above IP at the routing layer [RFC2328].
レイヤー2サブネットワークは、2つのシステムを接続するか、マルチポイントを接続することができます。Multipoint SubnetWorksは、放送（たとえば、共有メディアやエミュレート）または非ブロードキャストをブロードキャストできます。一般に、IPはマルチポイントサブネットワークを放送と見なし、共有中程度のイーサネットは標準（および歴史的）例として、ポイントツーポイントサブネットワークを縮退したケースと見なします。非ブロードキャストサブネットワークには、ルーティングレイヤー[RFC2328]のIPより上の追加メカニズムが必要になる場合があります。
IP is ignorant of the topology of the subnetwork layer. In particular, reconfiguration of subnetwork paths is not tracked by the IP layer. IP is only affected by whether it can send/receive packets sent to the remotely connected systems via the subnetwork interface (i.e., the reachability from one router to another). IP further considers that subnetworks are largely static -- that both their membership and existence are stable at routing timescales (tens of seconds); changes to these are considered re-provisioning, rather than routing.
IPは、サブネットワークレイヤーのトポロジーについて無知です。特に、サブネットワークパスの再構成は、IPレイヤーによって追跡されません。IPは、サブネットワークインターフェイスを介してリモート接続されたシステムに送信されたパケットを送信/受信できるかどうかのみの影響を受けます（つまり、あるルーターから別のルーターへの到達可能性）。IPは、サブネットワークは大部分が静的であると考えています。メンバーシップと存在の両方がルーティングタイムスケール（数秒）で安定していると考えています。これらの変更は、ルーティングではなく、再構成と見なされます。
Routing functionality in a subnetwork is related to addressing in that subnetwork. Resolution of addresses on subnetwork links is required for forwarding IP packets across links (e.g., ARP for IPv4, or ND for IPv6). There is unlikely to be direct interaction between subnetwork routing and IP routing. Where broadcast is provided or explicitly emulated, address resolution can be used directly; where not provided, the link layer routing may interface to a protocol for resolution, e.g., to the Next-Hop Resolution Protocol [RFC2322] to provide context-dependent address resolution capabilities.
サブネットワークのルーティング機能は、そのサブネットワークでのアドレス指定に関連しています。サブネットワークリンクのアドレスの解像度は、リンク全体にIPパケットを転送するために必要です（例：IPv4のARP、またはIPv6のND）。サブネットワークルーティングとIPルーティングの間に直接的な相互作用が発生する可能性は低いです。ブロードキャストが提供されるか、明示的にエミュレートされている場合、アドレス解決を直接使用できます。提供されていない場合、リンクレイヤールーティングは、解像度のためのプロトコル、たとえば次のホップ解像度プロトコル[RFC2322]にインターフェイスして、コンテキスト依存のアドレス解決機能を提供することができます。
Subnetwork routing can either complement or compete with IP routing. It complements IP when a subnetwork encapsulates its internal routing, and where the effects of that routing are not visible at the IP layer. However, if different paths in the subnetwork have characteristics that affect IP routing, it can affect or even inhibit the convergence of IP routing.
サブネットワークルーティングは、IPルーティングを補完または競合できます。サブネットワークが内部ルーティングをカプセル化すると、IPレイヤーでそのルーティングの効果が見えない場合にIPを補完します。ただし、サブネットワーク内の異なるパスにIPルーティングに影響を与える特性がある場合、IPルーティングの収束に影響を与えるか、さらには阻害する可能性があります。
Routing protocols generally consider Layer-2 subnetworks, i.e., with subnet masks and no intermediate IP hops, to have uniform routing metrics to all members. Routing can break when a link's characteristics do not match the routing metric, in this case, e.g., when some member pairs have different path characteristics. Consider a virtual Ethernet subnetwork that includes both nearby (sub-millisecond latency) and remote (100's of milliseconds away) systems. Presenting that group as a single subnetwork means that some routing protocols will assume that all pairs have the same delay, and that that delay is small. Because this is not the case, the routing tables constructed may be suboptimal or may even fail to converge.
ルーティングプロトコルは、一般に、レイヤー2サブネットワーク、つまりサブネットマスクと中間IPホップを使用して、すべてのメンバーに均一なルーティングメトリックを持つことを検討します。ルーティングは、リンクの特性がルーティングメトリックと一致しない場合に壊れる可能性があります。この場合、たとえば、一部のメンバーペアが異なるパス特性を持っている場合。近くの（サブミリ秒レイテンシ）とリモート（100秒のミリ秒離れた）システムの両方を含む仮想イーサネットサブネットワークを考えてみましょう。そのグループを単一のサブネットワークとして提示することは、いくつかのルーティングプロトコルがすべてのペアに同じ遅延があり、その遅延が小さいことを想定することを意味します。これはそうではないため、構築されたルーティングテーブルは最適ではない場合があるか、収束に失敗する可能性があります。
When a subnetwork is used for transit between a set of routers, it conventionally provides the equivalent of a full mesh of point-to-point links. Simplicity of the internal subnet structure can be used (e.g., via NHRP [RFC2332]) to reduce the size of address resolution tables, but routing exchanges will continue to reflect the full mesh they emulate. In general, subnetworks should not be used as a transit among a set of routers where routing protocols would break if a full mesh of equivalent point-to-point links were used.
サブネットワークがルーターのセット間のトランジットに使用される場合、従来、ポイントツーポイントリンクの完全なメッシュに相当するものを提供します。内部サブネット構造の単純さを使用して（たとえば、NHRP [RFC2332]介して）、アドレス解像度テーブルのサイズを縮小しますが、ルーティング交換はエミュレートする完全なメッシュを反映し続けます。一般に、サブネットワークは、同等のポイントツーポイントリンクの完全なメッシュが使用された場合、ルーティングプロトコルが壊れるルーターのセット間のトランジットとして使用すべきではありません。
Some subnetworks have special features that allow the use of more effective or responsive routing mechanisms that cannot be implemented in IP because of its need for generality. One example is the self-learning bridge algorithm widely used in Ethernet networks. Learning bridges perform Layer-2 subnetwork forwarding, avoiding the need for dynamic routing at each subnetwork hop. Another is the "handoff" mechanism in cellular telephone networks, particularly the "soft handoff" scheme in IS-95 CDMA.
一部のサブネットワークには、一般性が必要なため、IPで実装できない、より効果的またはレスポンシブルーティングメカニズムを使用できる特別な機能があります。1つの例は、イーサネットネットワークで広く使用されている自己学習ブリッジアルゴリズムです。学習ブリッジは、各サブネットワークホップで動的ルーティングの必要性を回避し、レイヤー2サブネットワークの転送を実行します。もう1つは、セルラー電話ネットワークの「ハンドオフ」メカニズム、特にIS-95 CDMAの「ソフトハンドオフ」スキームです。
Subnetworks that cover large geographic areas or include links of widely-varying capabilities should be avoided. IP routing generally considers all multipoint subnets equivalent to a local, shared-medium link with uniform metrics between any pair of systems, and ignores internal subnetwork topology. Where a subnetwork diverges from that assumption, it is the obligation of subnetwork designers to provide compensating mechanisms. Not doing so can affect the scalability and convergence of IP routing, as noted above.
大きな地理的領域をカバーする、または広く変化する機能のリンクを含むサブネットワークは避ける必要があります。IPルーティングは、一般に、すべてのマルチポイントサブネットを、システム間の均一なメトリックとローカル共有メディアムリンクに相当すると見なし、内部サブネットワークトポロジを無視します。サブネットワークがその仮定とは分岐している場合、サブネットワーク設計者が補償メカニズムを提供する義務です。そうしないと、上記のように、IPルーティングのスケーラビリティと収束に影響を与える可能性があります。
The subnetwork designer who decides to implement internal routing should consider whether a custom routing algorithm is warranted, or if an existing Internet routing algorithm or protocol may suffice. The designer should consider whether this decision is to reduce the address resolution table size (possible, but with additional protocol support required), or is trying to reduce routing table complexity. The latter may be better achieved by partitioning the subnetwork, either physically or logically, and using network-layer protocols to support partitioning (e.g., AS's in BGP). Protocols and routing algorithms can be notoriously subtle, complex, and difficult to implement correctly. Much work can be avoided if existing protocols or implementations can be readily reused.
内部ルーティングを実装することを決定したサブネットワーク設計者は、カスタムルーティングアルゴリズムが保証されているかどうか、または既存のインターネットルーティングアルゴリズムまたはプロトコルで十分であるかどうかを検討する必要があります。設計者は、この決定がアドレス解像度のテーブルサイズを削減することであるか（可能ですが、追加のプロトコルサポートが必要です）、またはルーティングテーブルの複雑さを削減しようとしているかどうかを検討する必要があります。後者は、物理的または論理的にサブネットワークをパーティション化し、ネットワーク層プロトコルを使用してパーティション化をサポートすることにより、より適切に実現することができます（たとえば、BGPのAS）。プロトコルとルーティングアルゴリズムは、微妙で複雑で、正しく実装するのが難しいことで有名です。既存のプロトコルまたは実装を容易に再利用できる場合、多くの作業を回避できます。
Security has become a high priority in the design and operation of the Internet. The Internet is vast, and countless organizations and individuals own and operate its various components. A consensus has emerged for what might be called a "security placement principle": a security mechanism is most effective when it is placed as close as possible to, and under the direct control of the owner of the asset that it protects.
セキュリティは、インターネットの設計と運用において最優先事項となっています。インターネットは膨大であり、無数の組織や個人がさまざまなコンポーネントを所有および運営しています。「セキュリティプレースメント原則」と呼ばれる可能性のあるものに対してコンセンサスが浮上しています。セキュリティメカニズムは、可能な限り近くに配置され、保護する資産の所有者の直接制御の下で最も効果的です。
A corollary of this principle is that end-to-end security (e.g., confidentiality, authentication, integrity, and access control) cannot be ensured with subnetwork security mechanisms. Not only are end-to-end security mechanisms much more closely associated with the end-user assets they protect, they are also much more comprehensive. For example, end-to-end security mechanisms cover gaps that can appear when otherwise good subnetwork mechanisms are concatenated. This is an important application of the end-to-end principle [SRC81].
この原則の結果は、サブネットワークのセキュリティメカニズムでは、エンドツーエンドのセキュリティ（たとえば、機密性、認証、整合性、アクセス制御）を確保できないことです。エンドツーエンドのセキュリティメカニズムは、保護するエンドユーザー資産とはるかに密接に関連しているだけでなく、もるかに包括的です。たとえば、エンドツーエンドのセキュリティメカニズムは、良好なサブネットワークメカニズムが連結されている場合に表示される可能性のあるギャップをカバーします。これは、エンドツーエンドの原則[SRC81]の重要なアプリケーションです。
Several security mechanisms that can be used end-to-end have already been deployed in the Internet and are enjoying increasing use. The most important are the Secure Sockets Layer (SSL) [SSL2] [SSL3] and TLS [RFC2246] primarily used to protect web commerce, Pretty Good Privacy (PGP) [RFC1991] and S/MIME [RFCs-2630-2634], primarily used to protect and authenticate email and software distributions, the Secure Shell (SSH), used for secure remote access and file transfer, and IPsec [RFC2401], a general purpose encryption and authentication mechanism that sits just above IP and can be used by any IP application. (IPsec can actually be used either on an end-to-end basis or between security gateways that do not include either or both end systems.)
エンドツーエンドを使用できるいくつかのセキュリティメカニズムは、すでにインターネットに展開されており、使用が増えています。最も重要なのは、主にWebコマース、かなり良いプライバシー（PGP）[RFC1991]およびS/MIME [RFCS-2630-2634]を保護するために使用されるセキュアソケット層（SSL）[SSL2] [SSL3]およびTLS [RFC2246]です。主に、電子メールとソフトウェアの分布を保護および認証するために使用されます。セキュアリモートアクセスとファイル転送に使用される安全なシェル（SSH）、およびIPのすぐ上にあり、IPのすぐ上にある汎用の暗号化と認証メカニズムであるIPSEC [RFC2401]が使用されます。任意のIPアプリケーション。（IPSECは、実際には、エンドツーエンドベースで、またはどちらかのエンドシステムまたは両方のシステムを含まないセキュリティゲートウェイ間で使用できます。）
Nonetheless, end-to-end security mechanisms are not used as widely as might be desired. However, the group could not reach consensus on whether subnetwork designers should be actively encouraged to implement mechanisms to protect user data.
それにもかかわらず、エンドツーエンドのセキュリティメカニズムは、望まれるほど広く使用されていません。ただし、グループは、ユーザーデータを保護するためのメカニズムを実装するように積極的に奨励されるべきかどうかについて、グループはコンセンサスに達することができませんでした。
The clear consensus of the working group held that subnetwork security mechanisms, especially when weak or incorrectly implemented [BGW01], may actually be counterproductive. The argument is that subnetwork security mechanisms can lull end users into a false sense of security, diminish the incentive to deploy effective end-to-end mechanisms, and encourage "risky" uses of the Internet that would not be made if users understood the inherent limits of subnetwork security mechanisms.
ワーキンググループの明確なコンセンサスは、サブネットワークのセキュリティメカニズムが、特に弱いまたは誤って実装された場合[BGW01]が実際に逆効果である可能性があると判断しました。議論は、サブネットワークのセキュリティメカニズムがエンドユーザーを誤ったセキュリティ感覚に抑え、効果的なエンドツーエンドメカニズムを展開するインセンティブを減らし、ユーザーが固有のものを理解した場合に行われないインターネットの「危険な」使用を奨励することができるということです。サブネットワークセキュリティメカニズムの制限。
The other point of view encourages subnetwork security on the principle that it is better than the default situation, which all too often is no security at all. Users of especially vulnerable subnets (such as consumers who have wireless home networks and/or shared media Internet access) often have control over at most one endpoint -- usually a client -- and therefore cannot enforce the use of end-to-end mechanisms. However, subnet security can be entirely adequate for protecting low-valued assets against the most likely threats. In any event, subnet mechanisms do not preclude the use of end-to-end mechanisms, which are typically used to protect highly-valued assets. This viewpoint recognizes that many security policies implicitly assume that the entire end-to-end path is composed of a series of concatenated links that are nominally physically secured. That is, these policies assume that all endpoints of all links are trusted, and that access to the physical medium by attackers is difficult. To meet the assumptions of such policies, explicit mechanisms are needed for links (especially shared medium links) that lack physical protection. This, for example, is the rationale that underlies Wired Equivalent Privacy (WEP) in the IEEE 802.11 [IEEE80211] wireless LAN standard, and the Baseline Privacy Interface in the DOCSIS [DOCSIS1] [DOCSIS2] data over cable television networks standards.
もう1つの視点は、デフォルトの状況よりも優れているという原則でサブネットワークのセキュリティを奨励しています。特に脆弱なサブネット（ワイヤレスホームネットワークや共有メディアインターネットアクセスを持っている消費者など）のユーザーは、多くの場合、最大1つのエンドポイント（通常はクライアント）を制御し、したがって、エンドツーエンドのメカニズムの使用を強制することはできません。。ただし、サブネットセキュリティは、最も可能性の高い脅威から低価値の資産を保護するのに完全に適切です。いずれにせよ、サブネットメカニズムは、通常、高度に価値のある資産を保護するために使用されるエンドツーエンドメカニズムの使用を排除しません。この視点は、多くのセキュリティポリシーが、エンドツーエンドパス全体が名目上物理的に保護されている一連の連結リンクで構成されていることを暗黙的に仮定していることを認識しています。つまり、これらのポリシーは、すべてのリンクのすべてのエンドポイントが信頼されており、攻撃者による物理媒体へのアクセスが困難であると仮定しています。そのようなポリシーの仮定を満たすために、物理的保護を欠くリンク（特に共有された媒体リンク）には明示的なメカニズムが必要です。たとえば、これは、IEEE 802.11 [IEEE80211]ワイヤレスLAN標準の有線同等のプライバシー（WEP）の根底にある理論的根拠と、ケーブルテレビネットワークの標準上のDOCSIS [docsis1] [docsis2]データのベースラインプライバシーインターフェイスです。
We therefore recommend that subnetwork designers who choose to implement security mechanisms to protect user data be as candid as possible with the details of such security mechanisms and the inherent limits of even the most secure mechanisms when implemented in a subnetwork rather than on an end-to-end basis.
したがって、ユーザーデータを保護するためのセキュリティメカニズムを実装することを選択したサブネットワーク設計者は、そのようなセキュリティメカニズムの詳細と、エンドツーではなくサブネットワークで実装された場合、最も安全なメカニズムの固有の限界でさえ、可能な限り率直にすることをお勧めします。 - エンドベース。
In keeping with the "placement principle", a clear consensus exists for another subnetwork security role: the protection of the subnetwork itself. Possible threats to subnetwork assets include theft of service and denial of service; shared media subnets tend to be especially vulnerable to such attacks. In some cases, mechanisms that protect subnet assets can also improve (but cannot ensure) end-to-end security.
「配置原則」に沿って、別のサブネットワークセキュリティの役割、つまりサブネットワーク自体の保護に明確なコンセンサスが存在します。サブネットワーク資産に対する脅威の可能性には、サービスの盗難とサービスの拒否が含まれます。共有メディアサブネットは、このような攻撃に対して特に脆弱である傾向があります。場合によっては、サブネット資産を保護するメカニズムは、エンドツーエンドのセキュリティを改善する（確実ではない）こともできます。
One security service can be provided by the subnetwork that will aid in the solution of an overall Internet problem: subnetwork security should provide a mechanism to authenticate the source of a subnetwork frame. This function is missing in some current protocols, e.g., the use of ARP [RFC826] to associate an IPv4 address with a MAC address. The IPv6 Neighbor Discovery (ND) [RFC2461] performs a similar function.
インターネット全体の問題の解決を支援するサブネットワークによって1つのセキュリティサービスを提供できます。サブネットワークセキュリティは、サブネットワークフレームのソースを認証するメカニズムを提供する必要があります。この関数は、現在のプロトコル、たとえばARP [RFC826]を使用してIPv4アドレスをMACアドレスに関連付けることです。IPv6 Neighbor Discovery（ND）[RFC2461]は同様の機能を実行します。
There are well-known security flaws with this address resolution mechanism [Wilbur89]. However, the inclusion of subnetwork frame source authentication will permit a secure subnetwork address.
このアドレス解決メカニズムを備えたよく知られているセキュリティの欠陥があります[Wilbur89]。ただし、サブネットワークフレームソース認証を含めると、安全なサブネットワークアドレスが可能になります。
Another potential role for subnetwork security is to protect users against traffic analysis, i.e., identifying the communicating parties and determining their communication patterns and volumes even when their actual contents are protected by strong end-to-end security mechanisms. Lower-layer security can be more effective against traffic analysis due to its inherent ability to aggregate the communications of multiple parties sharing the same physical facilities while obscuring higher-layer protocol information that indicates specific end points, such as IP addresses and TCP/UDP port numbers.
サブネットワークのセキュリティのもう1つの潜在的な役割は、ユーザーをトラフィック分析から保護することです。つまり、コミュニケーションの当事者を特定し、実際のコンテンツが強力なエンドツーエンドのセキュリティメカニズムによって保護されている場合でも、通信パターンとボリュームを決定することです。低層のセキュリティは、同じ物理施設を共有する複数の関係者の通信を集約する固有の能力により、IPアドレスやTCP/UDPポートなどの特定のエンドポイントを示す高層プロトコル情報を不明瞭にするため、トラフィック分析に対してより効果的になります。数字。
However, traffic analysis is a notoriously subtle and difficult threat to understand and defeat, far more so than threats to confidentiality and integrity. We therefore urge extreme care in the design of subnetwork security mechanisms specifically intended to thwart traffic analysis.
ただし、トラフィック分析は、機密性と誠実さに対する脅威よりもはるかに、理解して敗北することは、微妙で困難な脅威であることで有名です。したがって、私たちは、交通分析を阻止することを目的としたサブネットワークのセキュリティメカニズムの設計に極度の注意を促します。
Subnetwork designers must keep in mind that design and implementation for security is difficult [Schneier00]. [Schneier95] describes protocols and algorithms which are considered well-understood and believed to be sound.
サブネットワークの設計者は、セキュリティのための設計と実装が困難であることに留意する必要があります[Schneier00]。[Schneier95]は、よく理解されていると考えられていると考えられているプロトコルとアルゴリズムを説明しています。
Poor design process, subtle design errors and flawed implementation can result in gaping vulnerabilities. In recent years, a number of subnet standards have had problems exposed. The following are examples of mistakes that have been made:
デザインプロセスの低下、微妙な設計エラー、欠陥のある実装により、脆弱性が大きくなる可能性があります。近年、多くのサブネット標準が暴露された問題を抱えています。以下は、行われた間違いの例です。
1. Use of weak and untested algorithms [Crypto9912] [BGW01]. For a variety of reasons, algorithms were chosen which had subtle flaws, making them vulnerable to a variety of attacks.
1. 弱くてテストされていないアルゴリズムの使用[crypto9912] [BGW01]。さまざまな理由で、微妙な欠陥があるアルゴリズムが選択され、さまざまな攻撃に対して脆弱になりました。
2. Use of "security by obscurity" [Schneier00] [Crypto9912]. One common mistake is to assume that keeping cryptographic algorithms secret makes them more secure. This is intuitive, but wrong. Full public disclosure early in the design process attracts peer review by knowledgeable cryptographers. Exposure of flaws by this review far outweighs any imagined benefit from forcing attackers to reverse engineer security algorithms.
2. 「あいまいさによるセキュリティ」の使用[Schneier00] [Crypto9912]。よくある間違いの1つは、暗号化アルゴリズムを秘密にすることにより、より安全になると仮定することです。これは直感的ですが、間違っています。設計プロセスの初期の完全な公開は、知識豊富な暗号師によるピアレビューを魅了します。このレビューによる欠陥の露出は、攻撃者をリバースエンジニアのセキュリティアルゴリズムに強制することで想像上の利点をはるかに上回ります。
3. Inclusion of trapdoors [Schneier00] [Crypto9912]. Trapdoors are flaws surreptitiously left in an algorithm to allow it to be broken. This might be done to recover lost keys or to permit surreptitious access by governmental agencies. Trapdoors can be discovered and exploited by malicious attackers.
3. トラップドアの包含[Schneier00] [Crypto9912]。トラップドアは、アルゴリズムを壊すためにアルゴリズムにひそかに残っている欠陥です。これは、紛失した鍵を回復したり、政府機関による秘密のアクセスを許可するために行われる場合があります。トラップドアは、悪意のある攻撃者によって発見され、悪用されます。
4. Sending passwords or other identifying information as clear text. For many years, analog cellular telephones could be cloned and used to steal service. The cloners merely eavesdropped on the registration protocols that exchanged everything in clear text.
4. パスワードまたはその他の識別情報をクリアテキストとして送信します。長年にわたり、アナログの携帯電話をクローン化し、サービスを盗むために使用することができました。クロナーは、すべてを明確なテキストで交換した登録プロトコルを盗聴しただけです。
5. Keys which are common to all systems on a subnet [BGW01].
5. サブネット上のすべてのシステムに共通のキー[BGW01]。
6. Incorrect use of a sound mechanism. For example [BGW01], one subnet standard includes an initialization vector which is poorly designed and poorly specified. A determined attacker can easily recover multiple ciphertexts encrypted with the same key stream and perform statistical attacks to decipher them.
6. 健全なメカニズムの誤った使用。たとえば[BGW01]、1つのサブネット標準には、設計が不十分で、指定が不十分な初期化ベクトルが含まれています。決定された攻撃者は、同じキーストリームで暗号化された複数の暗号文を簡単に回復し、それらを解読するために統計攻撃を実行できます。
7. Identifying information sent in clear text that can be resolved to an individual, identifiable device. This creates a vulnerability to attacks targeted to that device (or its owner).
7. 個々の識別可能なデバイスに解決できる明確なテキストで送信された情報の識別。これにより、そのデバイス（またはその所有者）を対象とした攻撃に対する脆弱性が生じます。
8. Inability to renew and revoke shared secret information.
8. 共有された秘密情報を更新して取り消すことができない。
9. Insufficient key length.
9. キーの長さが不十分です。
10. Failure to address "man-in-the-middle" attacks, e.g., with mutual authentication.
10. 「中間者」の攻撃に対処できないこと、例えば相互認証を伴う。
11. Failure to provide a form of replay detection, e.g., to prevent a receiver from accepting packets from an attacker that simply resends previously captured network traffic.
11. たとえば、レシーバーが以前にキャプチャされたネットワークトラフィックを単純に再送信する攻撃者からパケットを受け入れるのを防ぐために、リプレイ検出の形式を提供できません。
12. Failure to provide integrity mechanisms when providing confidentiality schemes [Bel98].
12. 機密保持スキームを提供する際に整合性メカニズムを提供できない[bel98]。
This list is by no means comprehensive. Design problems are difficult to avoid, but expert review is generally invaluable in avoiding problems.
このリストは決して包括的ではありません。設計上の問題は避けるのが困難ですが、専門家のレビューは一般的に問題を回避する上で非常に貴重です。
In addition, well-designed security protocols can be compromised by implementation defects. Examples of such defects include use of predictable pseudo-random numbers [RFC1750], vulnerability to buffer overflow attacks due to unsafe use of certain I/O system calls [WFBA2000], and inadvertent exposure of secret data.
さらに、適切に設計されたセキュリティプロトコルは、実装の欠陥によって損なわれる可能性があります。このような欠陥の例には、予測可能な擬似ランダム数[RFC1750]の使用、特定のI/Oシステムコール[WFBA2000]の危険な使用による緩衝帯オーバーフロー攻撃に対する脆弱性、および秘密データの不注意な露出が含まれます。
This document represents a consensus of the members of the IETF Performance Implications of Link Characteristics (PILC) working group.
このドキュメントは、IETFのパフォーマンスのメンバーのコンセンサスを表しており、リンク特性（PILC）ワーキンググループのIETFパフォーマンスの意味合いを表しています。
This document would not have been possible without the contributions of a great number of people in the Performance Implications of Link Characteristics Working Group. In particular, the following people provided major contributions of text, editing, and advice on this document: Mark Allman provided the final editing to complete this document. Carsten Bormann provided text on robust header compression. Gorry Fairhurst provided text on broadcast and multicast issues, routing, and many valuable comments on the entire document. Aaron Falk provided text on bandwidth on demand. Dan Grossman provided text on many facets of the document. Reiner Ludwig provided thorough document review and text on TCP vs. Link-Layer Retransmission. Jamshid Mahdavi provided text on TCP performance calculations. Saverio Mascolo provided feedback on the document. Gabriel Montenegro provided feedback on the document. Marie-Jose Montpetit provided text on bandwidth on demand. Joe Touch provided text on multicast, broadcast, and routing, and Lloyd Wood provided many valuable comments on versions of the document.
このドキュメントは、リンク特性ワーキンググループのパフォーマンスへの影響における多くの人々の貢献なしには不可能でした。特に、次の人々は、このドキュメントに関するテキスト、編集、アドバイスの主要な貢献を提供しました。マーク・オールマンは、このドキュメントを完成させるために最終編集を提供しました。Carsten Bormannは、堅牢なヘッダー圧縮に関するテキストを提供しました。Gorry Fairhurstは、放送およびマルチキャストの問題、ルーティング、およびドキュメント全体に関する多くの貴重なコメントに関するテキストを提供しました。アーロンフォークは、帯域幅オンデマンドに関するテキストを提供しました。ダン・グロスマンは、ドキュメントの多くのファセットにテキストを提供しました。Reiner Ludwigは、TCP対Link-Layerの再送信に関する徹底的なドキュメントレビューとテキストを提供しました。Jamshid Mahdaviは、TCPパフォーマンス計算に関するテキストを提供しました。Saverio Mascoloは、ドキュメントに関するフィードバックを提供しました。ガブリエルモンテネグロは、ドキュメントに関するフィードバックを提供しました。Marie-Jose Montpetitは、オンデマンドで帯域幅にテキストを提供しました。Joe Touchはマルチキャスト、放送、ルーティングに関するテキストを提供し、ロイドウッドはドキュメントのバージョンに関する多くの貴重なコメントを提供しました。
References of the form RFCnnnn are Internet Request for Comments (RFC) documents available online at www.rfc-editor.org.
フォームの参照rfcnnnnは、www.rfc-editor.orgでオンラインで入手可能なコメント（RFC）ドキュメントのインターネットリクエストです。
[802.1D] Information Technology Telecommunications and information exchange between systems Local and metropolitan area networks, Common specifications Media access control (MAC) bridges, IEEE 802.1D, 1998. ISO 15802-3.
[802.1d]情報技術の電気通信と情報交換ローカルおよびメトロポリタンエリアネットワーク、一般的な仕様メディアアクセス制御（MAC）ブリッジ、IEEE 802.1d、1998。ISO15802-3。
[802.1p] IEEE, 802.1p, Standard for Local and Metropolitan Area Networks - Supplement to Media Access Control (MAC) Bridges: Traffic Class Expediting and Multicast.
[802.1p] IEEE、802.1p、ローカルおよびメトロポリタンエリアネットワークの標準 - メディアアクセス制御（MAC）ブリッジのサプリメント：トラフィッククラスの迅速化とマルチキャスト。
[AP99] Allman, M. and V. Paxson, On Estimating End-to-End Network Path Properties, In Proceedings of ACM SIGCOMM 99.
[AP99] ACM SIGCOMM 99の議事録におけるエンドツーエンドのネットワークパスプロパティの推定について、Allman、M。およびV. Paxson。
[AR02] Acar, G. and C. Rosenberg, Weighted Fair Bandwidth-on-Demand (WFBoD) for Geo-Stationary Satellite Networks with On-Board Processing, Computer Networks, 39(1), 2002.
[AR02] Acar、G。およびC. Rosenberg、オンボード処理、コンピューターネットワーク、39（1）、2002を備えた地理測定衛星ネットワーク用の重み付きフェアバンド幅オンデマンド（WFBOD）。
[ATMFTM] The ATM Forum, "Traffic Management Specification, Version 4.0", April 1996, document af-tm-0056.000. http://www.atmforum.com/
[ATMFTM] ATMフォーラム、「トラフィック管理仕様、バージョン4.0」、1996年4月、文書AF-TM-0056.000。http://www.atmforum.com/
[BA02] Blanton, E. and M. Allman, On Making TCP More Robust to Packet Reordering. ACM Computer Communication Review, 32(1), January 2002.
[BA02] Blanton、E。およびM. Allman、TCPのパケットの並べ替えにより堅牢になったことについて。ACMコンピューター通信レビュー、32（1）、2002年1月。
[Bel98] Bellovin, S., "Cryptography and the Internet", in Proceedings of CRYPTO '98, August 1998. http://www.research.att.com/~smb/papers/inet-crypto.pdf
[Bel98] Bellovin、S。、「暗号化とインターネット」、1998年8月、Crypto '98の議事録。http：//www.research.att.com/~smb/papers/inet-crypto.pdf
[BGW01] Borisov, N., Goldberg, I. and D. Wagner, "Intercepting Mobile Communications: The Insecurity of 802.11," In Proceedings of ACM MobiCom, July 2001.
[BGW01] Borisov、N.、Goldberg、I。、およびD. Wagner、「モバイル通信の傍受：802.11の不安定性」、ACM Mobicomの議事録、2001年7月。
[BPK98] Balakrishnan, H., Padmanabhan, V. and R. Katz. "The Effects of Asymmetry on TCP Performance." ACM Mobile Networks and Applications (MONET), 1998.
[BPK98] Balakrishnan、H.、Padmanabhan、V。およびR. Katz。「TCPパフォーマンスに対する非対称性の影響。」ACMモバイルネットワークとアプリケーション（MONET）、1998年。
[BPS99] Bennet,, J.C.R., Partridge, C. and N. Shectman, "Packet Reordering is Not Pathological Network Behavior", IEEE/ACM Transactions on Networking, Vol. 7, No. 6, December 1999.
[BPS99] Bennet ,, J.C.R.、Partridge、C。およびN. Shectman、「パケットの並べ替えは病理学的ネットワークの動作ではありません」、IEEE/ACMトランザクションオンネットワーク、Vol。7、No。6、1999年12月。
[CGMP] Farinacci D., Tweedly A. and T. Speakman, "Cisco Group Management Protocol (CGMP)", 1996/1997. ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt
[CGMP] Farinacci D.、Tweedly A.およびT. Speakman、「Cisco Group Management Protocol（CGMP）」、1996/1997。ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt
[Crypto9912] Schneier, B., "European Cellular Encryption Algorithms" Crypto-Gram, December 15, 1999. http://www.counterpane.com
[Crypto9912] Schneier、B。、 "欧州細胞暗号化アルゴリズム" Crypto-gram、1999年12月15日。http：//www.counterpane.com
[DIX82] Digital Equipment Corp, Intel Corp, Xerox Corp, Ethernet Local Area Network Specification Version 2.0, November 1982.
[DIX82] Digital Equipment Corp、Intel Corp、Xerox Corp、イーサネットローカルエリアネットワーク仕様バージョン2.0、1982年11月。
[DOCSIS1] Data-Over-Cable Service Interface Specifications, Radio Frequency Interface Specification 1.0, SP-RFI-I05- 991105, November 1999, Cable Television Laboratories, Inc.
[DOCSIS1]データオーバーサービスインターフェイス仕様、無線周波数インターフェイス仕様1.0、SP-RFI-I05- 991105、1999年11月、Cable Television Laboratories、Inc。
[DOCSIS2] Data-Over-Cable Service Interface Specifications, Radio Frequency Interface Specification 1.1, SP-RFIv1.1-I05- 000714, July 2000, Cable Television Laboratories, Inc.
[DOCSIS2]データオーバーサービスインターフェイス仕様、無線周波数インターフェイス仕様1.1、SP-RFIV1.1-I05- 000714、2000年7月、Cable Television Laboratories、Inc。
[DOCSIS3] Lai, W.S., "DOCSIS-Based Cable Networks: Impact of Large Data Packets on Upstream Capacity", 14th ITC Specialists Seminar on Access Networks and Systems, Barcelona, Spain, April 25-27, 2001.
[Docsis3] Lai、W.S。、「Docsisベースのケーブルネットワーク：上流容量に対する大規模なデータパケットの影響」、14回目のITCスペシャリストセミナーAccess Networks and Systems、スペイン、バルセロナ、4月25〜27日、2001年。
[EN301192] ETSI, European Broadcasting Union, Digital Video Broadcasting (DVB); DVB Specification for Data Broadcasting, European Standard (Telecommunications Series) EN 301 192 v1.2.1(1999-06).
[EN301192] ETSI、欧州放送組合、デジタルビデオ放送（DVB）;データ放送のDVB仕様、European Standard（Telecommunications Series）EN 301 192 v1.2.1（1999-06）。
[ES00] Eckhardt, D. and P. Steenkiste, "Effort-limited Fair (ELF) Scheduling for Wireless Networks, Proceedings of IEEE Infocom 2000.
[ES00] Eckhardt、D。およびP. Steenkiste、「努力制限公正（ELF）ワイヤレスネットワークのスケジューリング、IEEE Infocom 2000の議事録。
[FB00] Firoiu V. and M. Borden, "A Study of Active Queue Management for Congestion Control" to appear in Infocom 2000.
[FB00] Firoiu V.およびM. Borden、「混雑制御のためのアクティブキュー管理の研究」InfoCom 2000に登場。
[GM02] Grieco1, L. and S. Mascolo, "TCP Westwood and Easy RED to Improve Fairness in High-Speed Networks", Proceedings of the 7th International Workshop on Protocols for High-Speed Networks, April 2002.
[GM02] Grieco1、L。、およびS. Mascolo、「TCP Westwood and Easy Red of High Speed Networksの公平性を改善する」、2002年4月、高速ネットワークのプロトコルに関する第7回国際ワークショップの議事録。
[IEEE8023] IEEE 802.3 CSMA/CD Access Method. http://standards.ieee.org/
[IEEE8023] IEEE 802.3 CSMA/CDアクセス法。http://standards.ieee.org/
[IEEE80211] IEEE 802.11 Wireless LAN standard. http://standards.ieee.org/
[IEEE80211] IEEE 802.11ワイヤレスLAN標準。http://standards.ieee.org/
[ISO3309] ISO/IEC 3309:1991(E), "Information Technology - Telecommunications and information exchange between systems - High-level data link control (HDLC) procedures - Frame structure", International Organization For Standardization, Fourth edition 1991- 06-01.
[ISO3309] ISO/IEC 3309：1991（e）、「情報技術 - システム間の通信と情報交換 - 高レベルデータリンク制御（HDLC）手順 - フレーム構造」、国際標準化組織1991- 06-01。
[ISO13818] ISO/IEC, ISO/IEC 13818-1:2000(E) Information Technology - Generic coding of moving pictures and associated audio information: Systems, Second edition, 2000-12-01 International Organization for Standardization and International Electrotechnical Commission.
[ISO13818] ISO/IEC、ISO/IEC 13818-1：2000（e）情報技術 - 移動写真と関連するオーディオ情報の一般的なコーディング：システム、第2版、2000-12-01国際標準化および国際電気技術委員会。
[ITU-I363] ITU-T I.363.5 B-ISDN ATM Adaptation Layer Specification Type AAL5, International Standards Organisation (ISO), 1996.
[ITU-I363] ITU-T I.363.5 B-ISDN ATM適応層仕様タイプAAL5、International Standards Organization（ISO）、1996。
[Jac90] Jacobson, V., Modified TCP Congestion Avoidance Algorithm. Email to the end2end-interest mailing list, April 1990. ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt
[JAC90] Jacobson、V.、修正TCP混雑回避アルゴリズム。1990年4月、end2end-interestメーリングリストにメールしてください。ftp：//ftp.ee.lbl.gov/email/vanj.90apr30.txt
[KY02] Khafizov, F. and M. Yavuz, Running TCP Over IS-2000, Proceedings of IEEE ICC, 2002.
[KY02] Khafizov、F。およびM. Yavuz、IS-2000でTCPを実行している、IEEE ICCの議事録、2002年。
[LK00] Ludwig, R. and R. H. Katz, "The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions", ACM Computer Communication Review, Vol. 30, No. 1, January 2000.
[LK00] Ludwig、R。およびR. H. Katz、「アイフェルアルゴリズム：スプリアスレトランミッションに対してTCPを堅牢にする」、ACM Computer Communication Review、Vol。30、No。1、2000年1月。
[LKJK02] Ludwig, R., Konrad, A., Joseph, A. D. and R. H. Katz, "Optimizing the End-to-End Performance of Reliable Flows over Wireless Links", Kluwer/ACM Wireless Networks Journal, Vol. 8, Nos. 2/3, pp. 289-299, March-May 2002.
[LKJK02] Ludwig、R.、Konrad、A.、Joseph、A。D.、およびR. H. Katz、「ワイヤレスリンクを介した信頼できるフローのエンドツーエンドのパフォーマンスの最適化」、Kluwer/ACM Wireless Networks Journal、vol。8、Nos。2/3、pp。289-299、2002年3月 - 5月。
[LRKOJ99] Ludwig, R., Rathonyi, B., Konrad, A., Oden, K. and A. Joseph, Multi-Layer Tracing of TCP over a Reliable Wireless Link, pp. 144-154, In Proceedings of ACM SIGMETRICS 99.
[Lrkoj99] Ludwig、R.、Rathonyi、B.、Konrad、A.、Oden、K。およびA. Joseph、ACM Sigmetricsの議事録における信頼できるワイヤレスリンクを介したTCPのマルチレイヤートレース、pp。144-15499。
[LS00] Ludwig, R. and K. Sklower, The Eifel Retransmission Timer, ACM Computer Communication Review, Vol. 30, No. 3, July 2000.
[LS00] Ludwig、R。およびK. Sklower、The Eifel再送信タイマー、ACM Computer Communication Review、Vol。30、No。3、2000年7月。
[MAGMA-PROXY] Fenner, B., He, H., Haberman, B. and H. Sandick, "IGMP/MLD-based Multicast Forwarding ("IGMP/MLD Proxying")", Work in Progress.
[Magma-Proxy] Fenner、B.、He、H.、Haberman、B。、およびH. Sandick、「IGMP/MLDベースのマルチキャスト転送（「IGMP/MLDプロキシ」）」、進行中の作業。
[MAGMA-SNOOP] Christensen, M., Kimball, K. and F. Solensky, "Considerations for IGMP and MLD Snooping Switches", Work in Progress.
[Magma-Snoop] Christensen、M.、Kimball、K。and F. Solensky、「IGMPおよびMLD Snooping Switchesの考慮事項」、進行中の作業。
[MBB00] May, M., Bonald, T. and J-C. Bolot, "Analytic Evaluation of RED Performance", INFOCOM 2000.
[MBB00] May、M.、Bonald、T。、J-C。Bolot、「Red Performanceの分析評価」、Infocom 2000。
[MBDL99] May, M., Bolot, J., Diot, C. and B. Lyles, "Reasons not to deploy RED", Proc. of 7th. International Workshop on Quality of Service (IWQoS'99), June 1999.
[MBDL99] May、M.、Bolot、J.、Diot、C。、およびB. Lyles、「Redを展開しない理由」、Proc。7番目。1999年6月、サービス品質に関する国際ワークショップ（IWQOS'99）。
[MSMO97] Mathis, M., Semke, J., Mahdavi, J. and T. Ott, "The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm", Computer Communication Review, Vol. 27, number 3, July 1997.
[MSMO97] Mathis、M.、Semke、J.、Mahdavi、J。、およびT. Ott、「TCP輻輳回避アルゴリズムの巨視的挙動」、Computer Communication Review、Vol。27、3、1997年7月。
[MYR95] Boden, N., Cohen, D., Felderman, R., Kulawik, A., Seitz, C., et al. MYRINET: A Gigabit per Second Local Area Network, IEEE-Micro, Vol. 15, No.1, February 1995, pp. 29-36.
[Myr95] Boden、N.、Cohen、D.、Felderman、R.、Kulawik、A.、Seitz、C.、et al。Myrinet：1秒あたりのギガビット、ローカルエリアネットワーク、IEEE-Micro、Vol。15、No.1、1995年2月、pp。29-36。
[PFTK98] Padhye, J., Firoiu, V., Towsley, D. and J. Kurose, "Modeling TCP Throughput: a Simple Model and its Empirical Validation", UMASS CMPSCI Tech Report TR98- 008, Feb. 1998.
[PFTK98] Padhye、J.、Firoiu、V.、Towsley、D。、およびJ. Kurose、「Modeling TCP Sultput：単純なモデルとその経験的検証」、UMass CMPSCI Tech Report TR98- 008、1998年2月。
[RED93] Floyd, S. and V. Jacobson, "Random Early Detection gateways for Congestion Avoidance", IEEE/ACM Transactions in Networking, Vol. 1 No. 4, August 1993. http://www.aciri.org/floyd/papers/red/red.html
[Red93] Floyd、S。およびV. Jacobson、「混雑回避のためのランダムアーリー検出ゲートウェイ」、IEEE/ACMトランザクションにおけるトランザクション、Vol。1 No. 4、1993年8月。http：//www.aciri.org/floyd/papers/red/red.html
[RF95] Romanow, A. and S. Floyd, "Dynamics of TCP Traffic over ATM Networks". IEEE Journal of Selected Areas in Communication, Vol.13 No. 4, May 1995, p. 633-641.
[RF95] Romanow、A。およびS. Floyd、「ATMネットワーク上のTCPトラフィックのダイナミクス」。IEEE Journal of Communication in Communication、Vol.13 No. 4、1995年5月、p。633-641。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC826] Plummer, D.C., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48-bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC826] Plummer、D.C。、「イーサネットアドレス解像度プロトコル：または、イーサネットハードウェア上の送信のためにネットワークプロトコルアドレスを48ビットイーサネットアドレスに変換する」、1982年11月、STD 37、RFC 826、RFC 826。
[RFC1071] Braden, R., Borman, D. and C. Partridge, "Computing the Internet checksum", RFC 1071, September 1988.
[RFC1071] Braden、R.、Borman、D。、およびC. Partridge、「Internet Checksumのコンピューティング」、RFC 1071、1988年9月。
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144] Jacobson、V。、「低速シリアルリンクのTCP/IPヘッダーの圧縮」、RFC 1144、1990年2月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1332] McGregor, C., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332] McGregor、C。、「PPPインターネットプロトコル制御プロトコル（IPCP）」、RFC 1332、1992年5月。
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.
[RFC1435] Knowles、S。、「Path MTU Discoveryの経験からのIESGアドバイス」、RFC 1435、1993年3月。
[RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633] Braden、R.、Clark、D。、およびS. Shenker、「インターネットアーキテクチャにおける統合サービス：概要」、RFC 1633、1994年6月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W。、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC1662] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[RFC1662] Simpson、W.、ed。、「HDLCのようなフレーミングのPPP」、STD 51、RFC 1662、1994年7月。
[RFC1750] Eastlake 3rd, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750] EastLake 3rd、D.、Crocker、S。、およびJ. Schiller、「セキュリティのためのランダム性推奨」、RFC 1750、1994年12月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F.、ed。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939] Myers、J。およびM. Rose、「郵便局プロトコル -バージョン3」、STD 53、RFC 1939、1996年5月。
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、1996年8月。
[RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, August 1996.
[RFC1991] Atkins、D.、Stallings、W。and P. Zimmermann、「PGPメッセージ交換形式」、RFC 1991、1996年8月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[RFC2018] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Aumponredcement Options」、RFC 2018、1996年10月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、S。Jamin、「Resource Reservation Protocol（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O`Dell, M., Romanow, A., Weinrib, A. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment", RFC 2208, September 1997.
[RFC2208] Mankin、A.、Baker、F.、Braden、B.、Bradner、S.、O`dell、M.、Romanow、A.、Weinrib、A. and L. Zhang、リソース予約プロトコル（RSVP） - バージョン1の適用声明展開に関するいくつかのガイドライン」、RFC 2208、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[RFC2211] Wroclawski、J。、「制御されたロードネットワーク要素サービスの仕様」、RFC 2211、1997年9月。
[RFC2212] Shenker, S., Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212] Shenker、S.、Partridge、C。およびR. Guerin、「保証されたサービス品質の仕様」、RFC 2212、1997年9月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[RFC2309] Braden、B.、Clark、D.、Crowcroft、J.、Davie、B.、Deering、S.、Estrin、D.、Floyd、S.、Jacobson、V.、Minshall、G.、Partridge、C.、Peterson、L.、Ramakrishnan、K.、Shenker、S.、Wroclawski、J。and L. Zhang、「インターネットでのキュー管理と混雑回避に関する推奨事項」、RFC 2309、1998年4月。
[RFC2322] van den Hout, K., Koopal, A. and R. van Mook, "Management of IP numbers by peg-dhcp", RFC 2322, 1 April 1998.
[RFC2322] van den Hout、K.、Koopal、A。、およびR. Van Mook、「PEG-DHCPによるIP番号の管理」、RFC 2322、1998年4月1日。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[RFC2332] Luciani、J.、Katz、D.、Piscitello、D.、Cole、B。and N. Doraswamy、「NBMA Next Hop Resolution Protocol（NHRP）」、RFC 2332、1998年4月。
[RFC2364] Gross, G., Kaycee, M., Li, A., Malis, A. and J. Stephens, "PPP Over AAL5", RFC 2364, July 1998.
[RFC2364] Gross、G.、Kaycee、M.、Li、A.、Malis、A。、およびJ. Stephens、「PPP Over AAL5」、RFC 2364、1998年7月。
[RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394, December 1998.
[RFC2394]ペレイラ、R。、「DEFLATEを使用したIPペイロード圧縮」、RFC 2394、1998年12月。
[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, December 1998.
[RFC2395] Friend、R。およびR. Monsour、「LZSを使用したIPペイロード圧縮」、RFC 2395、1998年12月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406] Kent、S。およびR. Atkinson、「IPカプセンシングセキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[RFC2440] Callas、J.、Donnerhacke、L.、Finney、H。およびR. Thayer、「OpenPGPメッセージ形式」、RFC 2440、1998年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[RFC2507] Degermark、M.、Nordgren、B。およびS. Pink、「IPヘッダー圧縮」、RFC 2507、1999年2月。
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2508] Casner、S。およびV. Jacobson、「低速シリアルリンクのIP/UDP/RTPヘッダーの圧縮」、RFC 2508、1999年2月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。and W. Stevens、「TCP混雑制御」、RFC 2581、1999年4月。
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
[RFC2582] Floyd、S。およびT. Henderson、「TCPの高速回復アルゴリズムへのNewreno修正」、RFC 2582、1999年4月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597] Heinanen、J.、Baker、F.、Weiss、W。and J. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、 "Hypertext Transfer Protocol-HTTP/1.1"、RFC 2616、1999年6月。
[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[RFC2630] Housley、R。、「暗号化メッセージ構文」、RFC 2630、1999年6月。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[RFC2631] Rescorla、E。、「Diffie-Hellman Key Asmatement Method」、RFC 2631、1999年6月。
[RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate Handling", RFC 2632, June 1999.
[RFC2632] Ramsdell、B.、ed。、「S/Mimeバージョン3証明書処理」、RFC 2632、1999年6月。
[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[RFC2633] Ramsdell、B。、「S/Mimeバージョン3メッセージ仕様」、RFC 2633、1999年6月。
[RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[RFC2634] Hoffman、P。、「S/MIMEの強化されたセキュリティサービス」、RFC 2634、1999年6月。
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC2684] Grossman、D。およびJ. Heinanen、「ATM適応層5に対するマルチプロトコルカプセル化」、RFC 2684、1999年9月。
[RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
[RFC2686] Bormann、C。、「マルチリンクPPPへのマルチクラス拡張」、RFC 2686、1999年9月。
[RFC2687] Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing", RFC 2687, September 1999.
[RFC2687] Bormann、C。、「リアルタイム指向のHDLCのようなフレーミングのPPP」、RFC 2687、1999年9月。
[RFC2689] Bormann, C., "Providing Integrated Services over Low-bitrate Links", RFC 2689, September 1999.
[RFC2689] Bormann、C。、「低ビトレートリンクを介して統合サービスを提供する」、RFC 2689、1999年9月。
[RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710] Deering、S.、Fenner、W。and B. Haberman、「IPv6のマルチキャストリスナーディスカバリー（MLD）」、RFC 2710、1999年10月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。およびP. Traina、「Generic Routing Cancapstulation（GRE）」、RFC 2784、2000年3月。
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S。、「混雑制御原則」、BCP 41、RFC 2914、2000年9月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923] Lahey、K。、「Path MTU DiscoveryのTCP問題」、RFC 2923、2000年9月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988] Paxson、V。およびM. Allman、「TCPの再送信タイマーのコンピューティング」、RFC 2988、2000年11月。
[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.
[RFC2990] Huston、G。、「IP QoSアーキテクチャの次のステップ」、RFC 2990、2000年11月。
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S. and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[RFC3048] Whetten、B.、Vicisano、L.、Kermode、R.、Handley、M.、Floyd、S.、M。Luby、「1対Many Bulk-Data転送用の信頼できるマルチキャスト輸送ビルディングブロック」、RFC 3048、2001年1月。
[RFC3095] Bormann, C., Ed., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095] Bormann、C.、Ed。、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、L-E。、Hakenberg、R.、Koren、T.、Le、K。、Liu、Z.、Martensson、A.、Miyazaki、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T。、およびH. Zheng、 "Robust Header Compression（ROHC）：フレームワークと4つのプロファイル：RTP、UDP、ESP、および非圧縮 "、RFC 3095、2001年7月。
[RFC3096] Degermark, M., Ed., "Requirements for robust IP/UDP/RTP header compression", RFC 3096, July 2001.
[RFC3096] Degermark、M.、ed。、「堅牢なIP/UDP/RTPヘッダー圧縮の要件」、RFC 3096、2001年7月。
[RFC3150] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-to-end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001.
[RFC3150] Dawkins、S.、Montenegro、G.、Kojo、M。、およびV. Magret、「スローリンクのエンドツーエンドのパフォーマンスへの影響」、BCP 48、RFC 3150、2001年7月。
[RFC3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V. and N. Vaidya, "End-to-end Performance Implications of Links with Errors", BCP 50, RFC 3155, August 2001.
[RFC3155] Dawkins、S.、Montenegro、G.、Kojo、M.、Magret、V。、およびN. Vaidya、「エラーとリンクのエンドツーエンドのパフォーマンスへの影響」、BCP 50、RFC 3155、2001年8月。
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan、K.、Floyd、S。およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC3173] Shacham, A., Monsour, B., Pereira, R. and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001.
[RFC3173] Shacham、A.、Monsour、B.、Pereira、R。、およびM. Thomas、「IPペイロード圧縮プロトコル（IPComp）」、RFC 3173、2001年9月。
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246] Davie、B.、Charny、A.、Bennet、J.C.R.、Benson、K.、Le Boudec、J.Y.、Courtney、W.、Davari、S.、Firoiu、V。およびD. Stiliadis」PHB（PER-HOP行動）」、RFC 3246、2002年3月。
[RFC3248] Armitage, G., Carpenter, B., Casati, A., Crowcroft, J., Halpern, J., Kumar, B. and J. Schnizlein, "A Delay Bound alternative revision of RFC 2598", RFC 3248, March 2002.
[RFC3248] Armitage、G.、Carpenter、B.、Casati、A.、Crowcroft、J.、Halpern、J.、Kumar、B。、およびJ. Schnizlein、「RFC 2598の遅延結合代替改訂」、RFC 3248、2002年3月。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344] Perkins、C.、ed。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, August 2002.
[RFC3366] Fairhurst、G。およびL. Wood、「Link Automatic Repeat Request（ARQ）でデザイナーをリンクするアドバイス」、BCP 62、RFC 3366、2002年8月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。and A. Thyagarajan、 "Internet Group Management Protocol、Version 3"、RFC 3376、2002年10月。
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M. Sooriyabandara, "TCP Performance Implications of Network Path Asymmetry", BCP 69, RFC 3449, December 2002.
[RFC3449] Balakrishnan、H.、Padmanabhan、V.、Fairhurst、G。およびM. Sooriyabandara、「ネットワークパス非対称性のTCPパフォーマンスの影響」、BCP 69、RFC 3449、2002年12月。
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L. and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.
[RFC3450] Luby、M.、Gemmell、J.、Vicisano、L.、Rizzo、L。、およびJ. Crowcroft、「非同期層コーディング（ALC）プロトコルインスタンス化」、RFC 3450、2002年12月。
[RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002.
[RFC3451] Luby、M.、Gemmell、J.、Vicisano、L.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「レイヤードコーディング輸送（LCT）ビルディングブロック」、RFC 3451、2002年12月。
[RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[RFC3452] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「フォワードエラー補正（FEC）ビルディングブロック」、RFC 3452、2002年12月。
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[RFC3453] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「信頼できるマルチキャストでのフォワードエラー補正（FEC）の使用」、RFC 3453、2002年12月。
[RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group Management Protocol (RGMP)", RFC 3488, February 2003.
[RFC3488] Wu、I。およびT. Eckert、「Cisco Systems Router-Port-Port Group Management Protocol（RGMP）」、RFC 3488、2003年2月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] CRISPIN、M。、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 3501、2003年3月。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed. and G. Fairhurst, Ed., "The User Datagram Protocol (UDP)-Lite Protocol", RFC 3828, June 2004.
[RFC3828] Larzon、L-A。、Degermark、M.、Pink、S.、Jonsson、L-E。、ed。and G. Fairhurst、ed。、「ユーザーデータグラムプロトコル（UDP）ライトプロトコル」、RFC 3828、2004年6月。
[Schneier95] Schneier, B., Applied Cryptography: Protocols, Algorithms and Source Code in C (John Wiley and Sons, October 1995).
[Schneier95] Schneier、B。、Applied Cryptography：Cのプロトコル、アルゴリズム、ソースコード（John Wiley and Sons、1995年10月）。
[Schneier00] Schneier, B., Secrets and Lies: Digital Security in a Networked World (John Wiley and Sons, August 2000).
[Schneier00] Schneier、B.、Secrets and Lies：ネットワーク化された世界のデジタルセキュリティ（John Wiley and Sons、2000年8月）。
[SP2000] Stone, J. and C. Partridge, "When the CRC and TCP Checksum Disagree", ACM SIGCOMM, September 2000. http://www.acm.org/sigcomm/sigcomm2000/conf/ paper/sigcomm2000-9-1.pdf
[SP2000] Stone、J。およびC. Partridge、「CRCとTCPチェックサムが同意しないとき」、ACM Sigcomm、2000年9月。http：//www.acm.org/sigcomm/sigcomm2000/conf/ Paper/Sigcomm2000-9-9-1.pdf
[SRC81] Saltzer, J., Reed D. and D. Clark, "End-to-End Arguments in System Design". Second International Conference on Distributed Computing Systems (April, 1981) pages 509-512. Published with minor changes in ACM Transactions in Computer Systems 2, 4, November, 1984, pages 277-288. Reprinted in Craig Partridge, editor Innovations in internetworking. Artech House, Norwood, MA, 1988, pages 195-206. ISBN 0-89006-337-0.
[Src81] Saltzer、J.、Reed D.、D。Clark、「システム設計におけるエンドツーエンドの議論」。分散コンピューティングシステムに関する第2回国際会議（1981年4月）509-512ページ。1984年11月、コンピュータシステム2、4、4、ページ277-288のACMトランザクションのわずかな変更で公開されています。インターネットワーキングの編集者イノベーション、クレイグパートリッジで転載。Artech House、ノーウッド、マサチューセッツ州、1988年、195〜206ページ。ISBN 0-89006-337-0。
[SSL2] Hickman, K., "The SSL Protocol", Netscape Communications Corp., Feb 9, 1995.
[SSL2]ヒックマン、K。、「SSLプロトコル」、Netscape Communications Corp.、1995年2月9日。
[SSL3] Frier, A., Karlton, P. and P. Kocher, "The SSL 3.0 Protocol", Netscape Communications Corp., Nov 18, 1996.
[SSL3] Frier、A.、Karlton、P。and P. Kocher、「The SSL 3.0 Protocol」、Netscape Communications Corp.、1996年11月18日。
[TCPF98] Lin, D. and H.T. Kung, "TCP Fast Recovery Strategies: Analysis and Improvements", IEEE Infocom, March 1998. http://www.eecs.harvard.edu/networking/papers/infocom-tcp-final-198.pdf
[TCPF98] Lin、D。およびH.T.Kung、「TCP高速回復戦略：分析と改善」、IEEE Infocom、1998年3月。http：//www.eecs.harvard.edu/networking/papers/infocom-tcp-final-198.pdf
[WFBA2000] Wagner, D., Foster, J., Brewer, E. and A. Aiken, "A First Step Toward Automated Detection of Buffer Overrun Vulnerabilities", Proceedings of NDSS2000. http://www.isoc.org/isoc/conferences/ndss/ 2000/proceedings/039.pdf
[WFBA2000] Wagner、D.、Foster、J.、Brewer、E。、およびA. Aiken、「バッファオーバーラン脆弱性の自動検出に向けた最初のステップ」、NDSS2000の議事録。http://www.isoc.org/isoc/conferences/ndss/ 2000/proceedings/039.pdf
[Wilbur89] Wilbur, Steve R., Jon Crowcroft, and Yuko Murayama. "MAC layer Security Measures in Local Area Networks", Local Area Network Security, Workshop LANSEC '89 Proceedings, Springer-Verlag, April 1989, pp. 53-64.
[Wilbur89] Wilbur、Steve R.、Jon Crowcroft、およびYuko Murayama。「ローカルエリアネットワークのMACレイヤーセキュリティ対策」、ローカルエリアネットワークセキュリティ、ワークショップLANSEC '89 Proceedings、Springer-Verlag、1989年4月、pp。53-64。
Aaron Falk USC/Information Sciences Institute 4676 Admiralty Way Marina Del Rey, CA 90292
Aaron Falk USC/Information Sciences Institute 4676 Admiralty Way Marina Del Rey、CA 90292
Phone: 310-448-9327 EMail: falk@isi.edu
電話：310-448-9327メール：falk@isi.edu
Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica, Politecnico di Bari Via Orabona 4, 70125 Bari, Italy
Saverio Mascolo Dipartimento di Elettrotecnica Ed Elettronica、Politecnico di Bari経由でOrabona 4、70125 Bari、Italy
Phone: +39 080 596 3621
EMail: mascolo@poliba.it
URL: http://www-dee.poliba.it/dee-web/Personale/mascolo.html
Marie-Jose Montpetit MJMontpetit.com
Marie-Jose Montpetit mjmontpetit.com
EMail: marie@mjmontpetit.com
Phil Karn, Editor Qualcomm 5775 Morehouse Drive San Diego CA 92121
フィル・カーン、編集者QUALCOMM 5775 Morehouse Drive San Diego CA 92121
Phone: 858 587 1121 EMail: karn@qualcomm.com
電話：858 587 1121メール：karn@qualcomm.com
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, Germany
Carsten Bormann Universitaet Bremen Tzi Postfach 330440 D-28334ブレーメン、ドイツ
Phone: +49 421 218 7024
Fax: +49 421 218 7000
EMail: cabo@tzi.org
Godred (Gorry) Fairhurst Department of Engineering, University of Aberdeen, Aberdeen, AB24 3UE, United Kingdom
ゴッドレッド（ゴリー）フェアハースト工学部、アバディーン大学アバディーン、AB24 3UE、イギリス
EMail: gorry@erg.abdn.ac.uk
URL: http://www.erg.abdn.ac.uk/users/gorry
Dan Grossman Motorola, Inc. 111 Locke Drive Marlboro, MA 01752
Dan Grossman Motorola、Inc。111 Locke Drive Marlboro、MA 01752
EMail: Dan.Grossman@motorola.com
Reiner Ludwig Ericsson Research Ericsson Allee 1 52134 Herzogenrath, Germany
Reiner Ludwig Ericsson Research Ericsson Allee 1 52134 Herzogenrath、ドイツ
Phone: +49 2407 575 719 EMail: Reiner.Ludwig@ericsson.com Jamshid Mahdavi Novell, Inc.
電話：49 2407 575 719メール：reiner.ludwig@ericsson.com Jamshid Mahdavi Novell、Inc。
EMail: jmahdavi@earthlink.net
Gabriel Montenegro Sun Microsystems Laboratories, Europe 180, Avenue de l'Europe 38334 Saint Ismier CEDEX France
ガブリエルモンテネグロサンマイクロシステムラボラトリーズ、ヨーロッパ180、アベニューデルヨーロッパ38334セントイスミエセデックスフランス
EMail: gab@sun.com
Joe Touch USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey CA 90292
Joe Touch USC/Information Sciences Institute 4676 Admiralty Way Marina Del Rey CA 90292
Phone: 310 448 9151
EMail: touch@isi.edu
URL: http://www.isi.edu/touch
Lloyd Wood Cisco Systems 9 New Square Park, Bedfont Lakes Feltham TW14 8HA United Kingdom
ロイドウッドシスコシステム9ニュースクエアパーク、ベッドフォントレイクスフェルサムTW14 8haイギリス
Phone: +44 (0)20 8824 4236
EMail: lwood@cisco.com
URL: http://www.ee.surrey.ac.uk/Personal/L.Wood/
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。