RFC2681 日本語訳
2681 A Round-trip Delay Metric for IPPM. G. Almes, S. Kalidindi, M.Zekauskas. September 1999. (Format: TXT=44357 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Almes
Request for Comments: 2681 S. Kalidindi
Category: Standards Track M. Zekauskas
Advanced Network & Services
September 1999
Almesがコメントのために要求するワーキンググループG.をネットワークでつないでください: 2681秒間Kalidindiカテゴリ: 規格は1999年9月にM.Zekauskas高度なネットワークとサービスを追跡します。
A Round-trip Delay Metric for IPPM
IPPMにおける、メートル法の往復の遅れ
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
1. Introduction
1. 序論
This memo defines a metric for round-trip delay of packets across
Internet paths. It builds on notions introduced and discussed in the
IPPM Framework document, RFC 2330 [1], and follows closely the
corresponding metric for One-way Delay ("A One-way Delay Metric for
IPPM") [2]; the reader is assumed to be familiar with those
documents.
このメモはパケットの往復の遅れにおける、インターネット経路の向こう側のメートル法のaを定義します。 それは、IPPM Frameworkドキュメント、RFC2330[1]で紹介されて、議論した概念に建てて、密接にOne-道のDelay(「IPPMにおける、メートル法のA One-道の遅れ」)[2]における、メートル法の対応に続きます。 読者がそれらのドキュメントによく知られさせると思われます。
The memo was largely written by copying material from the One-way Delay metric. The intention is that, where the two metrics are similar, they will be described with similar or identical text, and that where the two metrics differ, new or modified text will be used.
メモは、One-道のDelayからメートル法で材料をコピーすることによって、主に書かれました。 意志は2つの測定基準が同様であるところで、それらが2つの測定基準が異なるところで同様の、または、同じテキスト、およびそれで説明されるでしょう、新しいか、または変更されたテキストが使用されるということです。
This memo is intended to be parallel in structure to a future companion document for Packet Loss.
このメモが構造でPacket Lossのための将来の仲間ドキュメントに平行であることを意図します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6]. Although RFC 2119 was written with protocols in mind, the key words are used in this document for similar reasons. They are used to ensure the results of measurements from two different implementations are comparable, and to note instances when an implementation could perturb the network.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[6]で説明されるように本書では解釈されることであるべきですか? RFC2119は念頭にプロトコルで書かれましたが、キーワードは本書では同様の理由に使用されます。 実現がネットワークを混乱させることができたとき、それらは2つの異なった実現からの測定値の結果が匹敵しているのを保証して、例に注意するのにおいて使用されています。
Almes, et al. Standards Track [Page 1] RFC 2681 Round-trip for Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の遅れにおける、往復の標準化過程[1ページ]RFC2681
The structure of the memo is as follows:
メモの構造は以下の通りです:
+ A 'singleton' analytic metric, called Type-P-Round-trip-Delay,
will be introduced to measure a single observation of round-trip
delay.
+A'単独個体'分析的である、メートル法であり、Type-Pの往復の遅れと呼ばれて、往復の遅れのただ一つの観測を測定するために導入するでしょう。
+ Using this singleton metric, a 'sample', called Type-P-Round-trip-
Delay-Poisson-Stream, will be introduced to measure a sequence of
singleton delays measured at times taken from a Poisson process.
+がポアソンが流すこの単独個体のメートル法の、そして、'サンプル'の、そして、呼ばれたType-P往復の遅れを使用して、ポアソン過程からかかる時間に測定された単独個体遅れの系列を測定するために導入するでしょう。
+ Using this sample, several 'statistics' of the sample will be
defined and discussed.
+がこのサンプルを使用して、サンプルの数個の'統計'について、定義されて、議論するでしょう。
This progression from singleton to sample to statistics, with clear separation among them, is important.
それらの中に明確な分離がある統計に抽出する単独個体からのこの進行は重要です。
Whenever a technical term from the IPPM Framework document is first used in this memo, it will be tagged with a trailing asterisk. For example, "term*" indicates that "term" is defined in the Framework.
IPPM Frameworkドキュメントからの専門用語が最初にこのメモで使用されるときはいつも、それは引きずっているアスタリスクでタグ付けをされるでしょう。 例えば、「用語*」は、「用語」がFrameworkで定義されるのを示します。
1.1. Motivation
1.1. 動機
Round-trip delay of a Type-P* packet from a source host* to a destination host is useful for several reasons:
送信元ホスト*からあて先ホストまでのType-P*パケットの往復の遅れはいくつかの理由の役に立ちます:
+ Some applications do not perform well (or at all) if end-to-end
delay between hosts is large relative to some threshold value.
ホストの間の終わりから終わりへの遅れが何らかの閾値に比例して大きいなら、+ いくつかのアプリケーションはよく振る舞いません(全く)。
+ Erratic variation in delay makes it difficult (or impossible) to
support many interactive real-time applications.
+ 遅れの不安定な変化は多くの対話的なリアルタイムのアプリケーションを支持するのを難しい、そして、(不可能)であるのにします。
+ The larger the value of delay, the more difficult it is for
transport-layer protocols to sustain high bandwidths.
+ 高帯域を支えるトランスポート層プロトコルのために、より大きい。遅れの値であり、それが難しければ難しいほど、
+ The minimum value of this metric provides an indication of the
delay due only to propagation and transmission delay.
+ これほどメートル法の最小値は伝播とトランスミッション遅れだけに当然の遅れのしるしを供給します。
+ The minimum value of this metric provides an indication of the
delay that will likely be experienced when the path* traversed is
lightly loaded.
+ これほどメートル法の最小値は*が横断した経路が軽くロードされるときおそらく経験される遅れのしるしを供給します。
+ Values of this metric above the minimum provide an indication of
the congestion present in the path.
+ これほどメートル法の値は最小限より上で経路の現在の混雑のしるしを供給します。
Almes, et al. Standards Track [Page 2] RFC 2681 Round-trip for Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の遅れにおける、往復の標準化過程[2ページ]RFC2681
The measurement of round-trip delay instead of one-way delay has several weaknesses, summarized here:
片道遅れの代わりに往復の遅れの測定には、ここへまとめられたいくつかの弱点があります:
+ The Internet path from a source to a destination may differ from
the path from the destination back to the source ("asymmetric
paths"), such that different sequences of routers are used for the
forward and reverse paths. Therefore round-trip measurements
actually measure the performance of two distinct paths together.
+ インターネット経路は目的地からソース(「非対称の経路」)まで経路とソースから目的地まで異なるかもしれません、ルータの異なった系列が前進の、そして、逆の経路に使用されるように。 したがって、往復の測定値は実際に2つの異なった経路の性能を一緒に測定します。
+ Even when the two paths are symmetric, they may have radically
different performance characteristics due to asymmetric queueing.
2つの経路でさえあるときに、+が左右対称である、それらには、非対称の待ち行列による根本的に異なった性能の特性があるかもしれません。
+ Performance of an application may depend mostly on the performance
in one direction.
+ アプリケーションのパフォーマンスは一方向でほとんど性能に依存するかもしれません。
+ In quality-of-service (QoS) enabled networks, provisioning in one
direction may be radically different than provisioning in the
reverse direction, and thus the QoS guarantees differ.
サービスの質(QoS)の可能にされたネットワークにおける+、一方向への食糧を供給するのは反対の方向への食糧を供給するのと根本的に異なるかもしれません、そして、その結果、QoS保証は異なります。
On the other hand, the measurement of round-trip delay has two specific advantages:
他方では、往復の遅れの測定には、2つの特定の利点があります:
+ Ease of deployment: unlike in one-way measurement, it is often
possible to perform some form of round-trip delay measurement
without installing measurement-specific software at the intended
destination. A variety of approaches are well-known, including
use of ICMP Echo or of TCP-based methodologies (similar to those
outlined in "IPPM Metrics for Measuring Connectivity" [4]).
However, some approaches may introduce greater uncertainty in the
time for the destination to produce a response (see
Section 2.7.3).
+ 展開の容易さ: 片道測定などと異なって、測定特有のソフトウェアを意図している目的地にインストールしないで何らかの形式の往復の遅れ測定を実行するのはしばしば可能です。 さまざまなアプローチが周知です、ICMP EchoかTCPベースの方法論の使用を含んでいて。(「測定の接続性のためのIPPM測定基準」[4])に概説されたものと同様です。 しかしながら、いくつかのアプローチが目的地が応答を起こす時間、よりすばらしい不確実性を導入するかもしれません(セクション2.7.3を見てください)。
+ Ease of interpretation: in some circumstances, the round-trip time
is in fact the quantity of interest. Deducing the round-trip time
from matching one-way measurements and an assumption of the
destination processing time is less direct and potentially less
accurate.
+ 解釈の容易さ: いくつかの事情では、事実上、往復の時間は興味がある量です。 合っている片道測定値からの往復の時間と目的地処理時間の仮定を推論するのはダイレクトになくて潜在的にそれほど正確ではありません。
1.2. General Issues Regarding Time
1.2. 時間に関する一般答弁
Whenever a time (i.e., a moment in history) is mentioned here, it is understood to be measured in seconds (and fractions) relative to UTC.
時間(すなわち、史上での瞬間)がここに言及されるときはいつも、秒(そして、断片)にUTCに比例してそれが測定されるのが理解されています。
As described more fully in the Framework document, there are four distinct, but related notions of clock uncertainty:
Frameworkドキュメントで、より完全に説明されるように、時計の不確実性の4つの異なりましたが、関連する概念があります:
Almes, et al. Standards Track [Page 3] RFC 2681 Round-trip for Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の遅れにおける、往復の標準化過程[3ページ]RFC2681
synchronization*
同期*
measures the extent to which two clocks agree on what time it
is. For example, the clock on one host might be 5.4 msec ahead
of the clock on a second host.
2個の時計が何時であるかに同意する範囲を測定します。 例えば、1人のホストの上の時計は5.4が2番目のホストの上の時計の前のmsecであるならそうするでしょうに。
accuracy*
精度*
measures the extent to which a given clock agrees with UTC. For
example, the clock on a host might be 27.1 msec behind UTC.
与えられた時計がUTCに同意する範囲を測定します。 例えば、ホストの上の時計は27.1がUTCの後ろのmsecであるならそうするでしょうに。
resolution*
解決*
measures the precision of a given clock. For example, the clock
on an old Unix host might tick only once every 10 msec, and thus
have a resolution of only 10 msec.
与えられた時計の精度を測定します。 例えば、年取ったUnixホストの上の時計は、かつてだけのあらゆる10msecのカチカチと音を立てて、その結果、10msecだけの解決を持っているかもしれません。
skew*
斜行*
measures the change of accuracy, or of synchronization, with
time. For example, the clock on a given host might gain 1.3
msec per hour and thus be 27.1 msec behind UTC at one time and
only 25.8 msec an hour later. In this case, we say that the
clock of the given host has a skew of 1.3 msec per hour relative
to UTC, which threatens accuracy. We might also speak of the
skew of one clock relative to another clock, which threatens
synchronization.
時間がある精度、または同期の変化を測定します。 例えば、与えられたホストの上の時計は、1時間単位で1.3msecを獲得して、その結果、ひところ、UTCの後ろの27.1msecであるかもしれなく、唯一の25.8は1時間後のmsecです。 この場合、私たちは、UTCに比例して与えられたホストの時計には1.3の斜行が毎時のmsecにあると言います。UTCは精度を脅かします。 また、私たちは別の時計に比例して1個の時計の斜行について話すかもしれません。時計は同期を脅かします。
2. A Singleton Definition for Round-trip Delay
2. 往復の遅れのためのシングルトンDefinition
2.1. Metric Name:
2.1. メートル法の名前:
Type-P-Round-trip-Delay
P往復の遅れをタイプしてください。
2.2. Metric Parameters:
2.2. メートル法のパラメタ:
+ Src, the IP address of a host
+ Src、ホストのIPアドレス
+ Dst, the IP address of a host
+ Dst、ホストのIPアドレス
+ T, a time
+T、時間
2.3. Metric Units:
2.3. メートル制:
The value of a Type-P-Round-trip-Delay is either a real number, or an undefined (informally, infinite) number of seconds.
または、Type-Pの往復の遅れの値が実数である、未定義である、(非公式である、無限) 秒数。
Almes, et al. Standards Track [Page 4] RFC 2681 Round-trip for Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の遅れにおける、往復の標準化過程[4ページ]RFC2681
2.4. Definition:
2.4. 定義:
For a real number dT, >>the *Type-P-Round-trip-Delay* from Src to Dst at T is dT<< means that Src sent the first bit of a Type-P packet to Dst at wire-time* T, that Dst received that packet, then immediately sent a Type-P packet back to Src, and that Src received the last bit of that packet at wire-time T+dT.
実数dTのために、Tの*タイプの>>P往復のSrcからDstまでの遅れ*はSrcがワイヤ時間*TでDstへのType-Pパケットの最初のビットを送ったdT<<手段であり、そのDstはそのパケットを受けて、次に、すぐに、Type-PパケットをSrcに送り返して、そのSrcはワイヤ時間T+dTでそのパケットの最後のビットを受けました。
>>The *Type-P-Round-trip-Delay* from Src to Dst at T is undefined (informally, infinite)<< means that Src sent the first bit of a Type-P packet to Dst at wire-time T and that (either Dst did not receive the packet, Dst did not send a Type-P packet in response, or) Src did not receive that response packet.
非公式に、無限) <<は、Srcがワイヤ時間TとそれでType-Pパケットの最初のビットをDstに送ったことを意味します。または、Tの*タイプの>>P往復のSrcからDstまでの遅れ*が未定義である、((Dstがパケットを受けないで、またDstが応答でType-Pパケットを送らなかった、)、Srcはその応答パケットを受けませんでした。
>>The *Type-P-Round-trip-Delay between Src and Dst at T<< means
either the *Type-P-Round-trip-Delay from Src to Dst at T or the
*Type-P-Round-trip-Delay from Dst to Src at T. When this notion is
used, it is understood to be specifically ambiguous which host acts
as Src and which as Dst. {Comment: This ambiguity will usually be a
small price to pay for being able to have one measurement, launched
from either Src or Dst, rather than having two measurements.}
>>TのSrcとDstの間の*タイプP往復の遅れ<<はTのSrcからDstまでの*タイプP往復の遅れか*がT.でDstからSrcまでP往復の遅れをタイプしているWhenのどちらかを意味します。使用されるこの概念、それがどのホストがSrcとして務めるか、そして、どれがDst務めるかが明確にあいまいであることが理解されています。 コメントしてください: 存在のために支払うわずかな価格が2つの測定を持っているよりむしろSrcかDstのどちらかから着手されたある測定を持つことができたなら通常、あいまいさが望んでいるこれ
Suggestions for what to report along with metric values appear in Section 3.8 after a discussion of the metric, methodologies for measuring the metric, and error analysis.
メートル法の数値と共に報告するべきことのための提案はメートル法(メートル法と誤り分析を測定するための方法論)の議論の後にセクション3.8に現れます。
2.5. Discussion:
2.5. 議論:
Type-P-Round-trip-Delay is a relatively simple analytic metric, and one that we believe will afford effective methods of measurement.
タイプのP往復の遅れがaである、比較的簡単である、分析的である、メートル法である、そして、私たちが測定の有効な手段を提供すると信じている1つ。
The following issues are likely to come up in practice:
以下の問題は実際には来そうです:
+ The timestamp values (T) for the time at which delays are measured
should be fairly accurate in order to draw meaningful conclusions
about the state of the network at a given T. Therefore, Src
should have an accurate knowledge of time-of-day. NTP [3] affords
one way to achieve time accuracy to within several milliseconds.
Depending on the NTP server, higher accuracy may be achieved, for
example when NTP servers make use of GPS systems as a time source.
Note that NTP will adjust the instrument's clock. If an
adjustment is made between the time the initial timestamp is taken
and the time the final timestamp is taken the adjustment will
affect the uncertainty in the measured delay. This uncertainty
must be accounted for in the instrument's calibration.
+ 遅れが測定される時のタイムスタンプ値(T)がネットワークの事情に関する重要な結論に与えられたT.Thereforeに達するためにかなり正確であるべきである、Srcには、時刻に関する正確な知識があるはずです。 NTP[3]は数ミリセカンドに時間精度を達成する1つの方法を提供します。 NTPサーバによって、より高い精度は達成されるかもしれません、例えば、NTPサーバが時間ソースとしてGPSシステムを利用するとき。 NTPが器具の時計を調整することに注意してください。 初期のタイムスタンプが取られる時、最終的なタイムスタンプが取られる時の間で調整をすると、調整は測定遅れにおける不確実性に影響するでしょう。 器具の較正でこの不確実性を説明しなければなりません。
Almes, et al. Standards Track [Page 5] RFC 2681 Round-trip for Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の遅れにおける、往復の標準化過程[5ページ]RFC2681
+ A given methodology will have to include a way to determine
whether a delay value is infinite or whether it is merely very
large (and the packet is yet to arrive at Dst). As noted by
Mahdavi and Paxson [4], simple upper bounds (such as the 255
seconds theoretical upper bound on the lifetimes of IP
packets [5]) could be used, but good engineering, including an
understanding of packet lifetimes, will be needed in practice.
{Comment: Note that, for many applications of these metrics, the
harm in treating a large delay as infinite might be zero or very
small. A TCP data packet, for example, that arrives only after
several multiples of the RTT may as well have been lost.}
+ 与えられた方法論は遅れ値が無限であるかどうか、またはそれが単に非常に大きいかどうか(パケットはまだDstに到着していません)決定する方法を含まなければならないでしょう。 Mahdaviとパクソン[4]、簡単な上限で注意される、(255がIPパケット[5])の生涯理論上の上限を後援するとき、そのようなものを使用できましたが、パケット生存期間の理解を含む良い工学が実際には必要でしょう。 {コメント: これらの測定基準、害の多くのアプリケーションによって無限がゼロであるかもしれないので大きい遅れを扱うか、非常に小さくそれに注意してください。 例えばRTTのいくつかの倍数の後にだけ到着するTCPデータ・パケットは失われるほうがよいです。}
+ If the packet is duplicated so that multiple non-corrupt instances
of the response arrive back at the source, then the packet is
counted as received, and the first instance to arrive back at the
source determines the packet's round-trip delay.
パケットであるなら+がコピーされるので、応答の複数の非不正な例がソースで帰って来ます、そして、次に、パケットは受け取るように数えられます、そして、ソースで帰って来る最初の例はパケットの往復の遅れを決定します。
+ If the packet is fragmented and if, for whatever reason,
reassembly does not occur, then the packet will be deemed lost.
パケットであり、断片化されて、再アセンブリがいかなる理由でも現れないなら、+はそうであり、次に、パケットは無くなると考えられるでしょう。
2.6. Methodologies:
2.6. 方法論:
As with other Type-P-* metrics, the detailed methodology will depend on the Type-P (e.g., protocol number, UDP/TCP port number, size, precedence).
他のType-P-*測定基準の場合、詳細な方法論はType-Pによるでしょう(例えば、プロトコル番号、UDP/TCPが数を移植します、サイズ、先行)。
Generally, for a given Type-P, the methodology would proceed as follows:
一般に、与えられたType-Pに関して、方法論は以下の通り続くでしょう:
+ At the Src host, select Src and Dst IP addresses, and form a test
packet of Type-P with these addresses. Any 'padding' portion of
the packet needed only to make the test packet a given size should
be filled with randomized bits to avoid a situation in which the
measured delay is lower than it would otherwise be due to
compression techniques along the path. The test packet must have
some identifying information so that the response to it can be
identified by Src when Src receives the response; one means to do
this is by placing the timestamp generated just before sending the
test packet in the packet itself.
+ Srcホスト、選んだSrc、Dst IPアドレス、および用紙のこれらのアドレスがあるType-Pのテストパケット。 単にテストパケットを与えられたサイズにするのが必要であるパケットのどんな'詰め物'部分も、経路に沿って、測定遅れがそうでなければ、それが圧縮のテクニックのためであるだろうより低い状況を避けるためにランダマイズされたビットで満たされるべきです。 テストパケットには、何らかの身元が分かる情報がSrcが応答を受けるとき、Srcがそれへの応答を特定できるように、なければなりません。 これをする1つの手段はパケット自体でテストパケットを送るすぐ前に発生したタイムスタンプを置くことです。
+ At the Dst host, arrange to receive and respond to the test
packet. At the Src host, arrange to receive the corresponding
response packet.
+、Dstホストでは、テストパケットに受信して、応じるように手配してください。 Srcホストでは、対応する応答パケットを受けるように手配してください。
Almes, et al. Standards Track [Page 6] RFC 2681 Round-trip for Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の遅れにおける、往復の標準化過程[6ページ]RFC2681
+ At the Src host, take the initial timestamp and then send the
prepared Type-P packet towards Dst. Note that the timestamp could
be placed inside the packet, or kept separately as long as the
packet contains a suitable identifier so the received timestamp
can be compared with the send timestamp.
Srcホスト、初期のタイムスタンプとその時がDstに向かった準備されたType-Pパケットを送る撮影における+。 パケットが受信されたタイムスタンプと比べることができるように適当な識別子を含んでいる限り、タイムスタンプをパケットの中に置いたか、または別々に保つことができたというメモ、タイムスタンプを送ってください。
+ If the packet arrives at Dst, send a corresponding response packet
back from Dst to Src as soon as possible.
+はパケットであるならDstに到着して、できるだけ早く、DstからSrcまで対応する応答パケットを返送してください。
+ If the response packet arrives within a reasonable period of time,
take the final timestamp as soon as possible upon the receipt of
the packet. By subtracting the two timestamps, an estimate of
round-trip delay can be computed. If the delay between the
initial timestamp and the actual sending of the packet is known,
then the estimate could be adjusted by subtracting this amount;
uncertainty in this value must be taken into account in error
analysis. Similarly, if the delay between the actual receipt of
the response packet and final timestamp is known, then the
estimate could be adjusted by subtracting this amount; uncertainty
in this value must be taken into account in error analysis. See
the next section, "Errors and Uncertainties", for a more detailed
discussion.
+は応答パケットであるなら適正な期間以内に到着して、できるだけ早く、パケットの領収書に最終的なタイムスタンプを持っていってください。 2つのタイムスタンプを引き算することによって、往復の遅れの見積りを計算できます。 初期のタイムスタンプとパケットの実際の発信の間の遅れが知られているなら、見積りはこの量を引き算することによって、調整されるかもしれません。 エラー解析でこの値における不確実性を考慮に入れなければなりません。 同様に、応答パケットと最終的なタイムスタンプの実際の領収書の間の遅れが知られているなら、見積りはこの量を引き算することによって、調整されるかもしれません。 エラー解析でこの値における不確実性を考慮に入れなければなりません。 より詳細な議論に関して次のセクションと、「誤りと不明確なこと」を見てください。
+ If the packet fails to arrive within a reasonable period of time,
the round-trip delay is taken to be undefined (informally,
infinite). Note that the threshold of 'reasonable' is a parameter
of the methodology.
+がパケットであるならa適正な期間中に到着しないで、未定義になるように往復の遅れを取る、(非公式である、無限) '妥当'の敷居が方法論のパラメタであることに注意してください。
Issues such as the packet format and the means by which Dst knows when to expect the test packet are outside the scope of this document.
このドキュメントの範囲の外にDstがいつテストパケットを予想するかを知っているパケット・フォーマットや手段などの問題があります。
{Comment: Note that you cannot in general add two Type-P-One-way-
Delay values (see [2]) to form a Type-P-Round-trip-Delay value. In
order to form a Type-P-Round-trip-Delay value, the return packet must
be triggered by the reception of a packet from Src.}
{コメント: 一般に、あなたがそうすることができないというメモは2Type-P片道の遅れの値を加えます。(Type-Pの往復の遅れ値を形成する[2])を見てください。 Type-Pの往復の遅れ値を形成するために、Srcからパケットのレセプションでリターンパケットを引き起こさなければなりません。}
{Comment: "ping" would qualify as a round-trip measure under this
definition, with a Type-P of ICMP echo request/reply with 60-byte
packets. However, the uncertainties associated with a typical ping
program must be analyzed as in the next section, including the type
of reflecting point (a router may not handle an ICMP request in the
fast path) and effects of load on the reflecting point.}
{コメント: 「ピング」はICMPエコー要求/回答のType-Pと共に60バイトのパケットで往復の測定のこの定義で資格を得るでしょう。 しかしながら、次のセクションのように典型的なピングプログラムに関連している不明確なことを分析しなければなりません、反射しているポイント(ルータは高速経路でICMP要求を扱わないかもしれない)のタイプと反射しているポイントへの負荷の効果を含んでいて。}
Almes, et al. Standards Track [Page 7] RFC 2681 Round-trip for Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の遅れにおける、往復の標準化過程[7ページ]RFC2681
2.7. Errors and Uncertainties:
2.7. 誤りと不明確なこと:
The description of any specific measurement method should include an accounting and analysis of various sources of error or uncertainty. The Framework document provides general guidance on this point, but we note here the following specifics related to delay metrics:
どんな特定の測定方法の記述も誤りか不確実性の様々な源の会計学と分析を含むべきです。 Frameworkドキュメントはこのポイントの上で一般的な指導を提供しますが、私たちは、ここで以下の詳細が遅れ測定基準に関連したことに注意します:
+ Errors or uncertainties due to uncertainty in the clock of the Src
host.
+ Srcホストの時計の不確実性による誤りか不明確なこと。
+ Errors or uncertainties due to the difference between 'wire time'
and 'host time'.
+ 'ワイヤ時間'と'ホスト時間'の違いによる誤りか不明確なこと。
+ Errors or uncertainties due to time required by the Dst to receive
the packet from the Src and send the corresponding response.
誤り..不確実性..時間..必要..受ける..パケット..送る..対応..応答
In addition, the loss threshold may affect the results. Each of
these are discussed in more detail below, along with a section
("Calibration") on accounting for these errors and uncertainties.
さらに、損失敷居は結果に影響するかもしれません。 これらの誤りと不明確なことのための会計のときにセクション(「較正」)と共にさらに詳細に以下でそれぞれのこれらについて議論します。
2.7.1. Errors or Uncertainties Related to Clocks
2.7.1. 時計に関連する誤りか不明確なこと
The uncertainty in a measurement of round-trip delay is related, in part, to uncertainty in the clock of the Src host. In the following, we refer to the clock used to measure when the packet was sent from Src as the source clock, and we refer to the observed time when the packet was sent by the source as Tinitial, and the observed time when the packet was received by the source as Tfinal. Alluding to the notions of synchronization, accuracy, resolution, and skew mentioned in the Introduction, we note the following:
往復の遅れの測定における不確実性はSrcホストの時計の不確実性に一部関係づけられます。 私たちは、以下では、私たちがパケットがいつソース時計としてSrcから送られたかを測定するのに使用される時計について言及して、パケットがソースによって送られた観測された時をTinitialと呼んで、Tfinalとしてパケットが情報筋によって受け取られた観測された時を呼びます。 Introductionで言及された同期、精度、解決、および斜行の概念について暗示して、私たちは以下に注意します:
+ While in one-way delay there is an issue of the synchronization of
the source clock and the destination clock, in round-trip delay
there is an (easier) issue of self-synchronization, as it were,
between the source clock at the time the test packet is sent and
the (same) source clock at the time the response packet is
received. Theoretically a very severe case of skew could threaten
this. In practice, the greater threat is anything that would
cause a discontinuity in the source clock during the time between
the taking of the initial and final timestamp. This might happen,
for example, with certain implementations of NTP.
そこの片道遅れで、+がソース時計と目的地時計の同期の問題である、応答パケットが受け取られているとき、往復の遅れには、テストパケットが送られる時のソース時計と(同じ)のソース時計の間には、自己同期の(より簡単)の問題がまるであります。 理論的に、斜行の非常に厳しいケースはこれを脅かすかもしれません。 実際には、より大きい脅威は時間初期的、そして、最終的なタイムスタンプの取りの間でソース時計で不連続を引き起こす何かです。 例えば、これはNTPのある実現で起こるかもしれません。
+ The accuracy of a clock is important only in identifying the time
at which a given delay was measured. Accuracy, per se, has no
importance to the accuracy of the measurement of delay.
+ 時計の精度は単に、与えられた遅れが測定された時を特定するのにおいて重要です。 精度はそういうものとして遅れの測定の精度に重要性を全く持っていません。
Almes, et al. Standards Track [Page 8] RFC 2681 Round-trip for Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の遅れにおける、往復の標準化過程[8ページ]RFC2681
+ The resolution of a clock adds to uncertainty about any time
measured with it. Thus, if the source clock has a resolution of
10 msec, then this adds 10 msec of uncertainty to any time value
measured with it. We will denote the resolution of the source
clock as Rsource.
+ 時計の解決はそれでいつでもに関して測定された不確実性に加えます。 したがって、ソース時計に10msecの解決があるなら、これはそれで測定されたどんな時間的価値にも不確実性の10msecを加えます。 私たちはRsourceとしてソース時計の解決を指示するつもりです。
Taking these items together, we note that naive computation Tfinal- Tinitial will be off by 2*Rsource.
これらの商品を一緒に取って、私たちは、ナイーブな計算Tfinal- Tinitialが2*Rsourceでオフになることに注意します。
2.7.2. Errors or Uncertainties Related to Wire-time vs Host-time
2.7.2. ワイヤ時間対ホスト時間まで関係づけられた誤りか不明確なこと
As we have defined round-trip delay, we would like to measure the time between when the test packet leaves the network interface of Src and when the corresponding response packet (completely) arrives at the network interface of Src, and we refer to these as "wire times". If the timings are themselves performed by software on Src, however, then this software can only directly measure the time between when Src grabs a timestamp just prior to sending the test packet and when it grabs a timestamp just after having received the response packet, and we refer to these two points as "host times".
私たちが往復の遅れを定義したとき、テストパケットがSrcのネットワーク・インターフェースを出る時、対応する応答パケットがSrcのネットワーク・インターフェースに(完全に)到着するという場合に時間を測定したいと思います、そして、私たちは「ワイヤ回」にこれらについて言及します。 しかしながら、タイミングがソフトウェアによってSrcに実行されるなら、このソフトウェアはちょうど、テストパケットを送る前、まさしく応答パケットを受けたとき後タイムスタンプをつかむ時Srcがタイムスタンプをつかむ時の間で直接時間を測定できるだけです、そして、私たちは「ホスト回」とこれらの2ポイントを呼びます。
Another contributor to this problem is time spent at Dst between the receipt there of the test packet and the sending of the response packet. Ideally, this time is zero; it is explored further in the next section.
この問題への別の貢献者はそこで領収書の間でDstでテストパケットと応答パケットの発信について費やされた時間です。 理想的に、今回はゼロです。 それは次のセクションで、より遠くに探検されます。
To the extent that the difference between wire time and host time is accurately known, this knowledge can be used to correct for host time measurements and the corrected value more accurately estimates the desired (wire time) metric.
正確にワイヤ時間とホスト時間の違いを知っていて、ホスト時に測定値と直っている値を修正するのにこの知識を使用できるという範囲まで、以上は正確にメートル法で必要を見積もっています(ワイヤ時間)。
To the extent, however, that the difference between wire time and host time is uncertain, this uncertainty must be accounted for in an analysis of a given measurement method. We denote by Hinitial an upper bound on the uncertainty in the difference between wire time and host time on the Src host in sending the test packet, and similarly define Hfinal for the difference on the Src host in receiving the response packet. We then note that these problems introduce a total uncertainty of Hinitial + Hfinal. This estimate of total wire-vs-host uncertainty should be included in the error/uncertainty analysis of any measurement implementation.
しかしながら、範囲に、与えられた測定方法の分析でワイヤ時間とホスト時間の違いが不確実であり、これが不確実性であることを説明しなければなりません。 私たちは、Srcホストの上で不確実性でHinitialでワイヤ時間とホスト時間の違いで上限をテストパケットを送るのにおいて指示して、違いのためにSrcホストの上で応答パケットを受ける際に同様にHfinalを定義します。 そして、私たちは、これらの問題がHinitial+Hfinalの総不確実性を導入することに注意します。 総ワイヤホストの不確実性のこの見積りはどんな測定実現の誤り/不確実性分析にも含まれるべきです。
2.7.3. Errors or Uncertainties Related to Dst Producing a Response
2.7.3. 誤りか不明確なことがDst生産に応答に関連しました。
Any time spent by the destination host in receiving and recognizing the packet from Src, and then producing and sending the corresponding response adds additional error and uncertainty to the round-trip delay measurement. The error equals the difference between the wire
Srcからのパケットがいつでも、あて先ホストに受信と認識に費やされて、次に、対応する応答を起こして、送ると、追加誤りと不確実性は往復の遅れ測定に加えられます。 誤りはワイヤの違いと等しいです。
Almes, et al. Standards Track [Page 9] RFC 2681 Round-trip for Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の遅れにおける、往復の標準化過程[9ページ]RFC2681
time the first bit of the packet is received by Dst and the wire time the first bit of the response is sent by Dst. To the extent that this difference is accurately known, this knowledge can be used to correct the desired metric. To the extent, however, that this difference is uncertain, this uncertainty must be accounted for in the error analysis of a measurement implementation. We denote this uncertainty by Hrefl. This estimate of uncertainty should be included in the error/uncertainty analysis of any measurement implementation.
パケットの最初のビットがDstによって受け取られる時、1番目が噛み付いた応答のワイヤ時はDstによって送られます。 正確にこの違いを知っていて、メートル法で必要を修正するのにこの知識を使用できるという範囲に。 しかしながら、範囲に、測定実現のエラー解析でこの違いが不確実であり、これが不確実性であることを説明しなければなりません。 私たちはHreflでこの不確実性を指示します。 不確実性のこの見積りはどんな測定実現の誤り/不確実性分析にも含まれるべきです。
2.7.4. Calibration
2.7.4. 較正
Generally, the measured values can be decomposed as follows:
一般に、以下の通り測定値を分解できます:
measured value = true value + systematic error + random error
測定値=真の値+系統誤差+無作為の誤り
If the systematic error (the constant bias in measured values) can be determined, it can be compensated for in the reported results.
系統誤差(測定値における一定の偏見)が決定できるなら、報告された結果でそれを補うことができます。
reported value = measured value - systematic error
報告された値=測定値--系統誤差
therefore
したがって
reported value = true value + random error
報告された値は真の値+無作為の誤りと等しいです。
The goal of calibration is to determine the systematic and random
error generated by the instruments themselves in as much detail as
possible. At a minimum, a bound ("e") should be found such that the
reported value is in the range (true value - e) to (true value + e)
at least 95 percent of the time. We call "e" the calibration error
for the measurements. It represents the degree to which the values
produced by the measurement instrument are repeatable; that is, how
closely an actual delay of 30 ms is reported as 30 ms. {Comment: 95
percent was chosen because (1) some confidence level is desirable to
be able to remove outliers, which will be found in measuring any
physical property; and (2) a particular confidence level should be
specified so that the results of independent implementations can be
compared.}
較正の目標は器具自体でできるだけ多くの詳細に発生する系統的で無作為の誤りを決定することです。 最小限では、バウンド(「e」)が見つけられるべきであるので、(真の値+e)には報告された値が範囲(真の値--e)に少なくとも95パーセントの割合であります。 私たちは、「e」を測定値のための校正誤差と呼びます。 それは測定器具によって生産された値が反復可能である程度を表します。 すなわち、30msの実際の遅れは30原稿としてどれくらい密接に報告されますか。コメントしてください: (1) 何らかの信頼水準がアウトライアー(どんな物理的性質も; (2) レベルが独立している実現の結果が比べることができるように指定されるべきであるという特別の信用を測定する際に見つけられるもの)を取り除くことができるのにおいて望ましいので、95パーセントは選ばれました。
From the discussion in the previous three sections, the error in measurements could be bounded by determining all the individual uncertainties, and adding them together to form
前の3つのセクションでの議論から、測定値における誤りは、すべての個々の不明確なことを決定することによってバウンドしていて、形成するためにそれらを合計しているかもしれません。
2*Rsource + Hinitial + Hfinal + Hrefl.
2*Rsource+Hinitial+Hfinal+Hrefl。
Almes, et al. Standards Track [Page 10] RFC 2681 Round-trip for Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の遅れにおける、往復の標準化過程[10ページ]RFC2681
However, reasonable bounds on both the clock-related uncertainty captured by the first term and the host-related uncertainty captured by the last three terms should be possible by careful design techniques and calibrating the instruments using a known, isolated, network in a lab.
しかしながら、前期によって得られた時計関連の不確実性と最後の3学期によって得られたホスト関連の不確実性の両方の妥当な領域は、研究室で知られていて、孤立しているネットワークを使用することで慎重な設計技術で可能、そして、器具を較正するべきです。
The host-related uncertainties, Hinitial + Hfinal + Hrefl, could be bounded by connecting two instruments back-to-back with a high-speed serial link or isolated LAN segment. In this case, repeated measurements are measuring the same round-trip delay.
ホスト関連の不明確なこと(Hinitial+Hfinal+Hrefl)は高速連続のリンクか孤立しているLANセグメントで2個の器具を接続することによって背中合わせの状態で境界があるかもしれません。 この場合、繰り返された測定値は同じ往復の遅れを測定しています。
If the test packets are small, such a network connection has a minimal delay that may be approximated by zero. The measured delay therefore contains only systematic and random error in the instrumentation. The "average value" of repeated measurements is the systematic error, and the variation is the random error.
テストパケットが小さいなら、そのようなネットワーク接続には、ゼロで近似されるかもしれない最小量の遅れがあります。 したがって、測定遅れは計装における系統的で無作為の誤りだけを含んでいます。 繰り返された測定値の「平均値」は系統誤差です、そして、変化は無作為の誤りです。
One way to compute the systematic error, and the random error to a
95% confidence is to repeat the experiment many times - at least
hundreds of tests. The systematic error would then be the median.
The random error could then be found by removing the systematic error
from the measured values. The 95% confidence interval would be the
range from the 2.5th percentile to the 97.5th percentile of these
deviations from the true value. The calibration error "e" could then
be taken to be the largest absolute value of these two numbers, plus
the clock-related uncertainty. {Comment: as described, this bound is
relatively loose since the uncertainties are added, and the absolute
value of the largest deviation is used. As long as the resulting
value is not a significant fraction of the measured values, it is a
reasonable bound. If the resulting value is a significant fraction
of the measured values, then more exact methods will be needed to
compute the calibration error.}
95%の信用に系統誤差、および無作為の誤りを計算する1つの方法は何回も実験を繰り返すことです--少なくとも何百ものテスト。 そして系統誤差はメディアンでしょう。 そして、測定値から系統誤差を取り除くことによって、無作為の誤りを見つけることができるでしょう。 2.5番目の百分順位から真の値からのこれらの逸脱の97.5番目の百分順位まで95%の信頼区間は範囲でしょう。 そして、これらの2つの番号の最も大きい絶対値と、時計関連の不確実性になるように校正誤差「e」を取ることができました。 {コメント: 説明されるように、不明確なことが加えられるので、このバウンドは比較的ゆるいです、そして、最も大きい逸脱の絶対値は使用されています。 結果として起こる値が測定値の重要な部分でない限り、それは合理的なバウンドです。 結果として起こる値が測定値の重要な部分であるなら、より正確な方法が、校正誤差を計算するのに必要でしょう。}
Note that random error is a function of measurement load. For example, if many paths will be measured by one instrument, this might increase interrupts, process scheduling, and disk I/O (for example, recording the measurements), all of which may increase the random error in measured singletons. Therefore, in addition to minimal load measurements to find the systematic error, calibration measurements should be performed with the same measurement load that the instruments will see in the field.
無作為の誤りが測定負荷の機能であることに注意してください。 例えば、多くの経路が1個の器具によって測定されるなら、これは中断、過程スケジューリング、およびディスク入出力(例えば、測定値を記録する)を増加させるかもしれません。そのすべてが測定単独個体における無作為の誤りを増加させるかもしれません。 したがって、系統誤差を見つける最小量の負荷測定値に加えて、較正測定は器具がその分野で見るのと同じ測定負荷で実行されるべきです。
We wish to reiterate that this statistical treatment refers to the calibration of the instrument; it is used to "calibrate the meter stick" and say how well the meter stick reflects reality.
この統計的な処理が器具の較正について言及するのを繰り返したいと思います。 それは、「メーター棒を較正し」て、メーター棒が現実をどれくらいよく反映するかを言うのに使用されます。
Almes, et al. Standards Track [Page 11] RFC 2681 Round-trip for Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の遅れにおける、往復の標準化過程[11ページ]RFC2681
In addition to calibrating the instruments for finite delay, two checks should be made to ensure that packets reported as losses were really lost. First, the threshold for loss should be verified. In particular, ensure the "reasonable" threshold is reasonable: that it is very unlikely a packet will arrive after the threshold value, and therefore the number of packets lost over an interval is not sensitive to the error bound on measurements. Second, consider the possibility that a packet arrives at the network interface, but is lost due to congestion on that interface or to other resource exhaustion (e.g. buffers) in the instrument.
有限遅れのために器具を較正することに加えて、損失が本当に負けられたのでパケットが報告したのを保証するのを2つのチェックをするべきです。 まず最初に、損失のための敷居は確かめられるべきです。 特に、「妥当な」敷居が確実に妥当になるようにしてください: パケットが閾値の後に到着するのが、非常にありそうもなく、したがって、間隔の間に失われたパケットの数が誤りに敏感でないことは測定値で付きました。 2番目に、パケットがネットワーク・インターフェースに到着しますが、混雑のためそのインタフェースの上、または、器具での他のリソース疲労困憊(例えば、バッファ)に失われている可能性を考えてください。
2.8. Reporting the Metric:
2.8. メートル法を報告します:
The calibration and context in which the metric is measured MUST be carefully considered, and SHOULD always be reported along with metric results. We now present four items to consider: the Type-P of test packets, the threshold of infinite delay (if any), error calibration, and the path traversed by the test packets. This list is not exhaustive; any additional information that could be useful in interpreting applications of the metrics should also be reported.
慎重に、メートル法が測定される較正と文脈を考えなければならない、SHOULD、メートル法の結果と共にいつも報告されてください。 私たちは現在、考えるために4つの項目を提示します: テストパケットのType-P、無限の遅れ(もしあれば)の敷居、誤り較正、およびテストパケットによって横断された経路。 このリストは徹底的ではありません。 また、どんな測定基準の応用を解釈する際に役に立つかもしれない追加情報も報告されるべきです。
2.8.1. Type-P
2.8.1. Pをタイプします。
As noted in the Framework document [1], the value of the metric may depend on the type of IP packets used to make the measurement, or "type-P". The value of Type-P-Round-trip-Delay could change if the protocol (UDP or TCP), port number, size, or arrangement for special treatment (e.g., IP precedence or RSVP) changes. The exact Type-P used to make the measurements MUST be accurately reported.
Frameworkドキュメント[1]に述べられるように、メートル法の値は測定をするのに使用されるIPパケット、または「タイプP」のタイプに頼るかもしれません。 Type-Pの往復の遅れの値は、特別な処理のためのプロトコル(UDPかTCP)、ポートナンバー、サイズ、またはアレンジメント(例えば、IP先行かRSVP)が変化するかどうかを変えるかもしれません。 正確に測定をするのに使用される正確なType-Pを報告しなければなりません。
2.8.2. Loss threshold
2.8.2. 損失敷居
In addition, the threshold (or methodology to distinguish) between a large finite delay and loss MUST be reported.
さらに、大きい有限遅れと損失の間の敷居(または、区別する方法論)を報告しなければなりません。
2.8.3. Calibration Results
2.8.3. 較正結果
+ If the systematic error can be determined, it SHOULD be removed
from the measured values.
+は系統誤差であるなら断固とする場合があって、それはSHOULDです。測定値から、取り除きます。
+ You SHOULD also report the calibration error, e, such that the
true value is the reported value plus or minus e, with 95%
confidence (see the last section.)
+ あなた、また、SHOULDは校正誤差を報告します、e、真の値が報告された値のプラスかマイナスeであるように、95%の自信をもって(最後のセクションを見てください。)
+ If possible, the conditions under which a test packet with finite
delay is reported as lost due to resource exhaustion on the
measurement instrument SHOULD be reported.
+ できれば有限であるのがあるテストパケットが延着する状態はそうです。測定器具SHOULDにおけるリソース疲労困憊のため失われているように報告されて、報告されてください。
Almes, et al. Standards Track [Page 12] RFC 2681 Round-trip for Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の遅れにおける、往復の標準化過程[12ページ]RFC2681
2.8.4. Path
2.8.4. 経路
Finally, the path traversed by the packet SHOULD be reported, if
possible. In general it is impractical to know the precise path a
given packet takes through the network. The precise path may be
known for certain Type-P on short or stable paths. For example, if
Type-P includes the record route (or loose-source route) option in
the IP header, and the path is short enough, and all routers* on the
path support record (or loose-source) route, and the Dst host copies
the path from Src to Dst into the corresponding reply packet, then
the path will be precisely recorded. This is impractical because the
route must be short enough, many routers do not support (or are not
configured for) record route, and use of this feature would often
artificially worsen the performance observed by removing the packet
from common-case processing. However, partial information is still
valuable context. For example, if a host can choose between two
links* (and hence two separate routes from Src to Dst), then the
initial link used is valuable context. {Comment: For example, with
Merit's NetNow setup, a Src on one NAP can reach a Dst on another NAP
by either of several different backbone networks.}
最終的に、経路はパケットでSHOULDを横断しました。可能であるなら、報告されてください。 一般に、与えられたパケットがネットワークを通して取る正確な経路を知るのは非実用的です。 正確な経路は短いか安定した経路のあるType-Pで知られているかもしれません。 例えば、Type-PがIPヘッダーで記録的なルート(または、ゆるい送信元経路)オプションを含めて、経路が十分短く、経路サポート記録(または、自由なソース)ルート、およびDstホストのすべてのルータ*がSrcからDstまで対応する回答パケットに経路をコピーすると、経路は正確に記録されるでしょう。 または、ルートが十分短くなければならないので、これは非実用的です、ルータが支持しない多く、(構成されない、)、ルートを記録してください。そうすれば、この特徴の使用はしばしば人工的によくある例処理からパケットを取り除くことによって観測された性能を悪化させるでしょう。 しかしながら、部分的な情報はまだ貴重な文脈です。 例えば、ホストが2個のリンク*を選ぶことができるなら(したがって、2はSrcからDstまでルートを切り離します)、使用される初期のリンクは貴重な文脈です。 例えば、MeritのNetNowセットアップ(1のNAPがいくつかの異なった背骨ネットワークについて別のNAPの上のDstに達することができるSrc)で以下について論評してください。
3. A Definition for Samples of Round-trip Delay
3. 往復の遅れのサンプルのための定義
Given the singleton metric Type-P-Round-trip-Delay, we now define one particular sample of such singletons. The idea of the sample is to select a particular binding of the parameters Src, Dst, and Type-P, then define a sample of values of parameter T. The means for defining the values of T is to select a beginning time T0, a final time Tf, and an average rate lambda, then define a pseudo-random Poisson process of rate lambda, whose values fall between T0 and Tf. The time interval between successive values of T will then average 1/lambda.
単独個体のメートル法のType-P往復の遅れを考えて、私たちは現在、そのような単独個体の1個の特定のサンプルを定義します。 サンプルの考えは、パラメタのSrc、Dst、およびType-Pの特定の結合を選択して、次に、パラメタT.の値のサンプルを定義することです。Tの値を定義するための手段は時間T0始めを選択することです、次に、Tf、および平均相場λが値がT0とTfで下落するレートλの擬似ランダムポアソンの過程を定義する最後の時代に。 そして、Tの連続した値の時間間隔は1/λを平均するでしょう。
{Comment: Note that Poisson sampling is only one way of defining a
sample. Poisson has the advantage of limiting bias, but other
methods of sampling might be appropriate for different situations.
We encourage others who find such appropriate cases to use this
general framework and submit their sampling method for
standardization.}
{コメント: ポアソン標本抽出がサンプルを定義することにおいて一方通行であるだけであることに注意してください。 ポアソンには、バイアスを制限する利点がありますが、異なった状況に、標本抽出の他の方法は適切であるかもしれません。 私たちは、そのような適切な場合を見つける他のものがこの一般的な枠組みを使用して、標準化のための自分達の標本抽出方法を提出するよう奨励します。}
3.1. Metric Name:
3.1. メートル法の名前:
Type-P-Round-trip-Delay-Poisson-Stream
タイプのP往復の遅れポアソンの流れ
Almes, et al. Standards Track [Page 13] RFC 2681 Round-trip for Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の遅れにおける、往復の標準化過程[13ページ]RFC2681
3.2. Metric Parameters:
3.2. メートル法のパラメタ:
+ Src, the IP address of a host
+ Src、ホストのIPアドレス
+ Dst, the IP address of a host
+ Dst、ホストのIPアドレス
+ T0, a time
+T0、時間
+ Tf, a time
+Tf、時間
+ lambda, a rate in reciprocal seconds
+ λ、相互的な秒のレート
3.3. Metric Units:
3.3. メートル制:
A sequence of pairs; the elements of each pair are:
組の系列。 それぞれの組の要素は以下の通りです。
+ T, a time, and
そして+T、時間。
+ dT, either a real number or an undefined number of seconds.
+ dT(実数か未定義の秒数のどちらか)。
The values of T in the sequence are monotonic increasing. Note that T would be a valid parameter to Type-P-Round-trip-Delay, and that dT would be a valid value of Type-P-Round-trip-Delay.
系列のTの値は単調な増加です。 TがType-Pの往復の遅れへの有効なパラメタであるだろう、dTがType-Pの往復の遅れの有効値であることに注意してください。
3.4. Definition:
3.4. 定義:
Given T0, Tf, and lambda, we compute a pseudo-random Poisson process beginning at or before T0, with average arrival rate lambda, and ending at or after Tf. Those time values greater than or equal to T0 and less than or equal to Tf are then selected. At each of the times in this process, we obtain the value of Type-P-Round-trip-Delay at this time. The value of the sample is the sequence made up of the resulting <time, delay> pairs. If there are no such pairs, the sequence is of length zero and the sample is said to be empty.
T0、Tf、およびλを考えて、私たちはT0かT0の前で平均到着率λで始まって、TfかTfの後に終わる擬似ランダムポアソンの過程を計算します。 それらの時間的価値、そして、T0と、よりTfは、より選択されます。 この過程によるそれぞれの時に、私たちはこのとき、Type-Pの往復の遅れの値を得ます。 遅れ>組、サンプルの値は結果として起こる<現代で作られた系列です。 何かそのような組がなければ、系列は長さゼロのものです、そして、サンプルは空であると言われています。
3.5. Discussion:
3.5. 議論:
The reader should be familiar with the in-depth discussion of Poisson sampling in the Framework document [1], which includes methods to compute and verify the pseudo-random Poisson process.
読者はFrameworkドキュメント[1]における、ポアソン標本抽出の徹底的な議論に詳しいはずです。(ドキュメントは擬似ランダムポアソンの過程を計算して、確かめる方法を含んでいます)。
We specifically do not constrain the value of lambda, except to note
the extremes. If the rate is too large, then the measurement traffic
will perturb the network, and itself cause congestion. If the rate
is too small, then you might not capture interesting network
behavior. {Comment: We expect to document our experiences with, and
suggestions for, lambda elsewhere, culminating in a "best current
practices" document.}
極端に注意する以外に、私たちは明確にλの値を抑制しません。 レートは大き過ぎて、次に、測定交通がネットワークを混乱させるということであるかどうか、そして、原因混雑自体。 レートがわずか過ぎるなら、あなたはおもしろいネットワークの振舞いを得ないかもしれません。 記録する: 私たちが経験を予想するコメント、および提案、ほかの場所の「最も良い現在の実務」ドキュメントに終わるλ。
Almes, et al. Standards Track [Page 14] RFC 2681 Round-trip for Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の遅れにおける、往復の標準化過程[14ページ]RFC2681
Since a pseudo-random number sequence is employed, the sequence of times, and hence the value of the sample, is not fully specified. Pseudo-random number generators of good quality will be needed to achieve the desired qualities.
擬似乱数列が採用しているので、回の系列、およびしたがって、サンプルの値は完全に指定されるというわけではありません。 良質の疑似乱数生成器が、必要な品質を獲得するのに必要でしょう。
The sample is defined in terms of a Poisson process both to avoid the
effects of self-synchronization and also capture a sample that is
statistically as unbiased as possible. {Comment: there is, of
course, no claim that real Internet traffic arrives according to a
Poisson arrival process.} The Poisson process is used to schedule
the delay measurements. The test packets will generally not arrive
at Dst according to a Poisson distribution, nor will response packets
arrive at Src according to a Poisson distribution, since they are
influenced by the network.
サンプルは、ともに、自己同期の効果を避けて、また、統計的にできるだけ不遍であることのサンプルを得るためにポアソン過程で定義されます。 コメント: もちろん、ポアソン到着の過程に従って本当のインターネットトラフィックが到着するというクレームが全くありません。 ポアソン過程は、遅れ測定の計画をするのに使用されます。 ポアソン分布に従って、一般に、テストパケットはDstに到着しないでしょう、そして、それらがネットワークによって影響を及ぼされるので、ポアソン分布に従って、応答パケットはSrcに到着しないでしょう。
All the singleton Type-P-Round-trip-Delay metrics in the sequence will have the same values of Src, Dst, and Type-P.
系列での単独個体Type-Pの往復の遅れ測定基準にはすべて、Src、Dst、およびType-Pの同じ値があるでしょう。
Note also that, given one sample that runs from T0 to Tf, and given new time values T0' and Tf' such that T0 <= T0' <= Tf' <= Tf, the subsequence of the given sample whose time values fall between T0' and Tf' are also a valid Type-P-Round-trip-Delay-Poisson-Stream sample.
'また、それに注意してください、新期間値T0と'Tf'をT0からTfまで動く1個のサンプルを与えて、考えてT0'<=Tf'T0<=<がTfと等しいように、またT0と'Tf'の間の時間的価値秋が有効なType-Pの往復の遅れポアソンの流れのサンプルである与えられたサンプルの続き。
3.6. Methodologies:
3.6. 方法論:
The methodologies follow directly from:
方法論は直接以下から従います。
+ the selection of specific times, using the specified Poisson
arrival process, and
そして+ 指定されたポアソン到着の過程を使用する特定の回の品揃え。
+ the methodologies discussion already given for the singleton Type-
P-Round-trip-Delay metric.
+ 単独個体のType- Pの往復の遅れのために既にメートル法でされた方法論議論。
Care must, of course, be given to correctly handle out-of-order arrival of test or response packets; it is possible that the Src could send one test packet at TS[i], then send a second test packet (later) at TS[i+1], and it could receive the second response packet at TR[i+1], and then receive the first response packet (later) at TR[i].
正しくテストか応答パケットの不適切な到着を扱うためにもちろん注意を与えなければなりません。 Srcが1つのテストパケットをTS[i]に送って、次に、(後で)TS[i+1]に2番目のテストパケットを送ることができたのが、可能であり、それは、TR[i+1]で2番目の応答パケットを受けて、次に、(後で)TR[i]で最初の応答パケットを受けるかもしれません。
3.7. Errors and Uncertainties:
3.7. 誤りと不明確なこと:
In addition to sources of errors and uncertainties associated with methods employed to measure the singleton values that make up the sample, care must be given to analyze the accuracy of the Poisson process with respect to the wire-times of the sending of the test packets. Problems with this process could be caused by several
サンプルを作る単独個体値を測定するのに使われる方法に関連している誤りと不明確なことの源に加えて、テストパケットの発信のワイヤ倍に関してポアソン過程の精度を分析するために注意を与えなければなりません。 この過程に関する問題は数個によって引き起こされる場合がありました。
Almes, et al. Standards Track [Page 15] RFC 2681 Round-trip for Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の遅れにおける、往復の標準化過程[15ページ]RFC2681
things, including problems with the pseudo-random number techniques
used to generate the Poisson arrival process, or with jitter in the
value of Hinitial (mentioned above as uncertainty in the singleton
delay metric). The Framework document shows how to use the
Anderson-Darling test to verify the accuracy of a Poisson process
over small time frames. {Comment: The goal is to ensure that test
packets are sent "close enough" to a Poisson schedule, and avoid
periodic behavior.}
Hinitial(単独個体遅れにおける不確実性として上にメートル法であることで言及される)の値にポアソン到着の過程を発生させるのに使用される擬似乱数のテクニック、またはジターに関する問題を含むもの。 Frameworkドキュメントは、小さい時間枠の上でポアソン過程の精度について確かめるのにどのようにアンダーソン-最愛の人テストを使用するかを示します。 コメント: 目標はテストパケットがポアソンスケジュールの「十分近く」という送って、ことであり、周期行動を避けるのを保証することです。
3.8. Reporting the Metric:
3.8. メートル法を報告します:
You MUST report the calibration and context for the underlying singletons along with the stream. (See "Reporting the metric" for Type-P-Round-trip-Delay.)
あなたは流れに伴う基本的な単独個体のための較正と文脈を報告しなければなりません。 (Type-Pの往復の遅れに関して「メートル法を報告します」を見てください。)
4. Some Statistics Definitions for Round-trip Delay
4. 往復の遅れのためのいくつかの統計定義
Given the sample metric Type-P-Round-trip-Delay-Poisson-Stream, we now offer several statistics of that sample. These statistics are offered mostly to be illustrative of what could be done.
サンプルのメートル法のType-P往復の遅れポアソンのストリームを考えて、私たちは現在、そのサンプルのいくつかの統計を提供します。 ほとんどできたことで説明に役立つようにこれらの統計を提供します。
4.1. Type-P-Round-trip-Delay-Percentile
4.1. P往復の遅れ百分順位をタイプしてください。
Given a Type-P-Round-trip-Delay-Poisson-Stream and a percent X between 0% and 100%, the Xth percentile of all the dT values in the Stream. In computing this percentile, undefined values are treated as infinitely large. Note that this means that the percentile could thus be undefined (informally, infinite). In addition, the Type-P- Round-trip-Delay-Percentile is undefined if the sample is empty.
0%と100%(StreamのすべてのdT値のXth百分順位)の間にType-Pの往復の遅れポアソンの流れとパーセントXを与えました。 この百分順位を計算する際に、未定義値は無限に大きいとして扱われます。 これが、その結果、百分順位が未定義であるかもしれないことを意味することに注意してください、(非公式である、無限) さらに、サンプルが空であるなら、Type-Pの往復の遅れ百分順位は未定義です。
Example: suppose we take a sample and the results are:
例: 私たちがサンプリングするか、そして、結果は以下の通りです。
Stream1 = <
<T1, 100 msec>
<T2, 110 msec>
<T3, undefined>
<T4, 90 msec>
<T5, 500 msec>
>
Stream1が<<T1と等しく、100msec>が<T2であり、110msec>が<T3であり、未定義の>が<T4であり、90msec>が<T5であり、500msec>は>です。
Then the 50th percentile would be 110 msec, since 90 msec and 100 msec are smaller and 110 msec and 'undefined' are larger.
次に、50番目の百分順位が110msecであるだろう、90以来、msecと100msecは、より小さい、そして、110msecで'未定義'が、より大きいということです。
Note that if the possibility that a packet with finite delay is reported as lost is significant, then a high percentile (90th or 95th) might be reported as infinite instead of finite.
有限遅れがあるパケットが失われているように報告される可能性が重要であるなら高い百分順位(90番目か95番目)が有限の代わりに無限であると報告されるかもしれないことに注意してください。
Almes, et al. Standards Track [Page 16] RFC 2681 Round-trip for Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の遅れにおける、往復の標準化過程[16ページ]RFC2681
4.2. Type-P-Round-trip-Delay-Median
4.2. P往復の遅れメディアンをタイプしてください。
Given a Type-P-Round-trip-Delay-Poisson-Stream, the median of all the dT values in the Stream. In computing the median, undefined values are treated as infinitely large. As with Type-P-Round-trip-Delay- Percentile, Type-P-Round-trip-Delay-Median is undefined if the sample is empty.
StreamでType-Pの往復の遅れポアソンの流れ、すべてのdT値のメディアンを与えます。 メディアンを計算する際に、未定義値は無限に大きいとして扱われます。 Type-P往復の遅れ百分順位のように、サンプルが空であるなら、Type-Pの往復の遅れメディアンは未定義です。
As noted in the Framework document, the median differs from the 50th percentile only when the sample contains an even number of values, in which case the mean of the two central values is used.
Frameworkドキュメントに述べられるように、サンプルが値の偶数を含む場合にだけ、メディアンは50番目の百分順位と異なっています、その場合、2つの代表値の平均が使用されています。
Example: suppose we take a sample and the results are:
例: 私たちがサンプリングするか、そして、結果は以下の通りです。
Stream2 = <
<T1, 100 msec>
<T2, 110 msec>
<T3, undefined>
<T4, 90 msec>
>
Stream2が<<T1と等しく、100msec>が<T2であり、110msec>が<T3であり、未定義の>が<T4であり、90msec>は>です。
Then the median would be 105 msec, the mean of 100 msec and 110 msec, the two central values.
次に、メディアンが105msecであるだろう、100の平均がmsecであり、110はmsec、2つの代表値です。
4.3. Type-P-Round-trip-Delay-Minimum
4.3. P往復の遅れ最小限をタイプしてください。
Given a Type-P-Round-trip-Delay-Poisson-Stream, the minimum of all the dT values in the Stream. In computing this, undefined values are treated as infinitely large. Note that this means that the minimum could thus be undefined (informally, infinite) if all the dT values are undefined. In addition, the Type-P-Round-trip-Delay-Minimum is undefined if the sample is empty.
StreamでType-Pの往復の遅れポアソンの流れ、すべてのdT値の最小限を与えます。 これを計算する際に、未定義値は無限に大きいとして扱われます。 これが、その結果、最小限が未定義であるかもしれないことを意味することに注意してください、(非公式である、無限) すべてのdT値が未定義であるなら。 さらに、サンプルが空であるなら、Type-Pの往復の遅れ最小限は未定義です。
In the above example, the minimum would be 90 msec.
上記の例では、最小限は90がmsecであるならそうするでしょうに。
4.4. Type-P-Round-trip-Delay-Inverse-Percentile
4.4. P往復の遅れ逆さの百分順位をタイプしてください。
Given a Type-P-Round-trip-Delay-Poisson-Stream and a time duration threshold, the fraction of all the dT values in the Stream less than or equal to the threshold. The result could be as low as 0% (if all the dT values exceed threshold) or as high as 100%. Type-P-Round- trip-Delay-Inverse-Percentile is undefined if the sample is empty.
Type-Pの往復の遅れポアソンの流れと時間持続時間敷居を考えて、すべてのdTの部分はStreamで、より敷居を評価します。 結果は100%と0同じくらい%(すべてのdT値が敷居を超えているなら)か同じくらい高く同じくらい低いかもしれません。 P丸いタイプ、-サンプルが空であるなら、旅行の遅れの逆さの百分順位は未定義です。
In the above example, the Inverse-Percentile of 103 msec would be 50%.
上記の例では、103のInverse-百分順位msecは50%でしょう。
Almes, et al. Standards Track [Page 17] RFC 2681 Round-trip for Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の遅れにおける、往復の標準化過程[17ページ]RFC2681
5. Security Considerations
5. セキュリティ問題
Conducting Internet measurements raises both security and privacy concerns. This memo does not specify an implementation of the metrics, so it does not directly affect the security of the Internet nor of applications which run on the Internet. However, implementations of these metrics must be mindful of security and privacy concerns.
インターネット測定値を行うと、セキュリティとプライバシーの問題の両方が提起されます。 このメモが測定基準の実現を指定しないので、それは直接インターネットで動くインターネットとアプリケーションのセキュリティに影響しません。 しかしながら、これらの測定基準の実現は心にセキュリティとプライバシーの問題をとどめていなければなりません。
There are two types of security concerns: potential harm caused by the measurements, and potential harm to the measurements. The measurements could cause harm because they are active, and inject packets into the network. The measurement parameters MUST be carefully selected so that the measurements inject trivial amounts of additional traffic into the networks they measure. If they inject "too much" traffic, they can skew the results of the measurement, and in extreme cases cause congestion and denial of service.
2つのタイプの安全上の配慮があります: 測定値によって引き起こされた潜在的害、および測定値への潜在的害。 測定値は、彼らがアクティブであるので害を引き起こして、ネットワークにパケットを注ぐかもしれません。 慎重に測定パラメタを選択しなければならないので、測定値は些細な量の追加交通を彼らが測定するネットワークに注ぎます。 「あまりに多く」の交通を注入するなら、彼らはサービスの測定の結果、極端な場合は原因混雑、および否定を歪曲できます。
The measurements themselves could be harmed by routers giving measurement traffic a different priority than "normal" traffic, or by an attacker injecting artificial measurement traffic. If routers can recognize measurement traffic and treat it separately, the measurements will not reflect actual user traffic. If an attacker injects artificial traffic that is accepted as legitimate, the loss rate will be artificially lowered. Therefore, the measurement methodologies SHOULD include appropriate techniques to reduce the probability measurement traffic can be distinguished from "normal" traffic. Authentication techniques, such as digital signatures, may be used where appropriate to guard against injected traffic attacks.
測定交通を異なった優先させるルータは交通の、または、攻撃者のそばで注入している「標準」人工の測定交通より測定自体に害を及ぼすことができました。 ルータが別々に測定交通を認識して、それを扱うことができると、測定値は実施している者交通を反映しないでしょう。 攻撃者が正統であるとして認められる人工の交通を注入すると、損失率は人工的に下げられるでしょう。 したがって、測定方法論SHOULDは、「正常な」交通と測定交通を区別できるという確率を減少させるために適切なテクニックを含んでいます。 デジタル署名などの認証のテクニックは注入された交通攻撃に用心するのが適切であるところで使用されるかもしれません。
The privacy concerns of network measurement are limited by the active measurements described in this memo. Unlike passive measurements, there can be no release of existing user data.
ネットワーク測定のプライバシーの問題はこのメモで説明されたアクティブな測定値によって制限されます。 受け身の測定値と異なって、既存の利用者データのリリースが全くあるはずがありません。
6. Acknowledgements
6. 承認
Special thanks are due to Vern Paxson and to Will Leland for several useful suggestions.
バーン・パクソンといくつかの役に立つ提案のためのウィル・リーランドに特別な感謝があります。
7. References
7. 参照
[1] Paxson, D., Almes, G., Mahdavi, J. and M. Mathis, "Framework for
IP Performance Metrics", RFC 2330, May 1998.
[1] パクソン、D.、Almes、G.、Mahdavi、J.、およびM.マシス(「IPパフォーマンス測定基準のための枠組み」、RFC2330)は1998がそうするかもしれません。
[2] Almes, G., Kalidindi,S. and M. Zekauskas, "A One-way Delay
Metric for IPPM", RFC 2679, September 1999.
[2]AlmesとG.とKalidindiとS.とM.Zekauskas、「IPPMにおける、メートル法のA One-道の遅れ」、RFC2679、1999年9月。
[3] Mills, D., "Network Time Protocol (v3)", RFC 1305, April 1992.
[3] 工場、D.、「ネットワーク時間プロトコル(v3)」、RFC1305、1992年4月。
Almes, et al. Standards Track [Page 18] RFC 2681 Round-trip for Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の遅れにおける、往復の標準化過程[18ページ]RFC2681
[4] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
Connectivity", RFC 2678, September 1999.
[4]Mahdavi、J.、および「測定の接続性のためのIPPM測定基準」、RFC2678、1999年9月対パクソン
[5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[5] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
8. Authors' Addresses
8. 作者のアドレス
Guy Almes Advanced Network & Services, Inc. 200 Business Park Drive Armonk, NY 10504 USA
奴のAlmesはネットワークを唱えて、Inc.200ビジネスパークDriveニューヨーク10504アーモンク(米国)にサービスを提供します。
Phone: +1 914 765 1120 EMail: almes@advanced.org
以下に電話をしてください。 +1 1120年の914 765メール: almes@advanced.org
Sunil Kalidindi Advanced Network & Services, Inc. 200 Business Park Drive Armonk, NY 10504 USA
Sunil Kalidindiはネットワークを唱えて、Inc.200ビジネスパークDriveニューヨーク10504アーモンク(米国)にサービスを提供します。
Phone: +1 914 765 1128 EMail: kalidindi@advanced.org
以下に電話をしてください。 +1 1128年の914 765メール: kalidindi@advanced.org
Matthew J. Zekauskas Advanced Network & Services, Inc. 200 Business Park Drive Armonk, NY 10504 USA
マシューJ.Zekauskasはネットワークを唱えて、Inc.200ビジネスパークDriveニューヨーク10504アーモンク(米国)にサービスを提供します。
Phone: +1 914 765 1112 EMail: matt@advanced.org
以下に電話をしてください。 +1 1112年の914 765メール: matt@advanced.org
Almes, et al. Standards Track [Page 19] RFC 2681 Round-trip for Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の遅れにおける、往復の標準化過程[19ページ]RFC2681
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Almes, et al. Standards Track [Page 20]
Almes、他 標準化過程[20ページ]
一覧
スポンサーリンク
