RFC2680 日本語訳

Network Working Group                                           G. Almes
Request for Comments: 2680                                  S. Kalidindi
Category: Standards Track                                   M. Zekauskas
                                             Advanced Network & Services
                                                          September 1999

Almesがコメントのために要求するワーキンググループG.をネットワークでつないでください: 2680秒間Kalidindiカテゴリ: 規格は1999年9月にM.Zekauskas高度なネットワークとサービスを追跡します。

                 A One-way Packet Loss Metric for IPPM

IPPMにおける、メートル法のA One-道のパケット損失

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 one-way packet loss across Internet
   paths.  It builds on notions introduced and discussed in the IPPM
   Framework document, RFC 2330 [1]; the reader is assumed to be
   familiar with that document.

このメモは片道パケット損失でのインターネット経路の向こう側のメートル法のaを定義します。 それはIPPM Frameworkドキュメント、RFC2330[1]で紹介されて、議論した概念に建てられます。 読者がそのドキュメントによく知られさせると思われます。

   This memo is intended to be parallel in structure to a companion
   document for One-way Delay ("A One-way Delay Metric for IPPM") [2];
   the reader is assumed to be familiar with that document.

このメモが構造でOne-道のDelay(「IPPMにおける、メートル法のA One-道の遅れ」)[2]のための仲間ドキュメントに平行であることを意図します。 読者がそのドキュメントによく知られさせると思われます。

   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 [5].
   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[5]で説明されるように本書では解釈されることであるべきですか? RFC2119は念頭にプロトコルで書かれましたが、キーワードは本書では同様の理由に使用されます。 実現がネットワークを混乱させることができたとき、それらは2つの異なった実現からの測定値の結果が匹敵しているのを保証して、例に注意するのにおいて使用されています。

   The structure of the memo is as follows:

メモの構造は以下の通りです:

   +  A 'singleton' analytic metric, called Type-P-One-way-Loss, is
      introduced to measure a single observation of packet transmission
      or loss.

+A'単独個体'分析的である、メートル法、Type-Pの片道損失と呼ばれて、パケット伝送か損失のただ一つの観測を測定するために導入します。

Almes, et al.               Standards Track                     [Page 1]

RFC 2680          One Way Packet Loss Metric for IPPM     September 1999

Almes、他 IPPM1999年9月のメートル法の標準化過程[1ページ]RFC2680一方通行のパケット損失

   +  Using this singleton metric, a 'sample', called Type-P-One-way-
      Loss-Poisson-Stream, is introduced to measure a sequence of
      singleton transmissions and/or losses measured at times taken from
      a Poisson process.

ポアソン過程からかかる時間に測定された単独個体送信、そして/または、損失の系列を測定するために+ このメートル法の単独個体a'サンプル'をポアソンが流す呼ばれたType-P片道の損失である使用するのを導入します。

   +  Using this sample, several 'statistics' of the sample are 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. 動機:

   Understanding one-way packet loss of Type-P* packets 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
      loss between hosts is large relative to some threshold value.

ホストの間の終わりからエンド・ロスが何らかの閾値に比例して大きいなら、+ いくつかのアプリケーションはよく振る舞いません(全く)。

   +  Excessive packet loss may make it difficult to support certain
      real-time applications (where the precise threshold of "excessive"
      depends on the application).

+ 過度のパケット損失で、あるリアルタイムのアプリケーション(「過度」の正確な敷居をアプリケーションに依存するところ)を支持するのは難しくなるかもしれません。

   +  The larger the value of packet loss, the more difficult it is for
      transport-layer protocols to sustain high bandwidths.

+ 高帯域を支えるトランスポート層プロトコルのために、より大きい。パケット損失の値であり、それが難しければ難しいほど、

   +  The sensitivity of real-time applications and of transport-layer
      protocols to loss become especially important when very large
      delay-bandwidth products must be supported.

+ リアルタイムのアプリケーションとトランスポート層プロトコルの感度は損失に非常に大きい遅れ帯域幅生成物を支えなければならないと特に重要な状態でなります。

   The measurement of one-way loss instead of round-trip loss is
   motivated by the following factors:

往復の損失の代わりに片道損失の測定は以下の要素によって動機づけられています:

   +  In today's Internet, the path from a source to a destination may
      be different than 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.  Measuring each path independently highlights the
      performance difference between the two paths which may traverse
      different Internet service providers, and even radically different
      types of networks (for example, research versus commodity
      networks, or ATM versus packet-over-SONET).

今日のインターネットの+、ソースから目的地までの経路は経路と目的地からソース(「非対称の経路」)まで異なるかもしれません、ルータの異なった系列が前進の、そして、逆の経路に使用されるように。 したがって、往復の測定値は実際に2つの異なった経路の性能を一緒に測定します。 独自に各経路を測定すると2つの経路の異なったインターネット接続サービス業者を横断するかもしれない性能差、および根本的に異なったタイプのネットワークさえ目立つ、(例えば、商品ネットワーク、またはATMに対して研究してください、パケット過剰Sonet、)

Almes, et al.               Standards Track                     [Page 2]

RFC 2680          One Way Packet Loss Metric for IPPM     September 1999

Almes、他 IPPM1999年9月のメートル法の標準化過程[2ページ]RFC2680一方通行のパケット損失

   +  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.  For example, a file transfer using TCP may
      depend more on the performance in the direction that data flows,
      rather than the direction in which acknowledgements travel.

+ アプリケーションのパフォーマンスは一方向でほとんど性能に依存するかもしれません。 例えば、TCPを使用するファイル転送はさらにデータが指示よりむしろ流れる方向への承認が旅行する性能に依存するかもしれません。

   +  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.  Measuring
      the paths independently allows the verification of both
      guarantees.

サービスの質(QoS)の可能にされたネットワークにおける+、一方向への食糧を供給するのは反対の方向への食糧を供給するのと根本的に異なるかもしれません、そして、その結果、QoS保証は異なります。 独自に経路を測定すると、両方の保証の検証は許されます。

   It is outside the scope of this document to say precisely how loss
   metrics would be applied to specific problems.

損失測定基準が正確にどう特定の問題に適用されるだろうかを言うために、このドキュメントの範囲の外にそれはあります。

1.2. General Issues Regarding Time

1.2. 時間に関する一般答弁

   {Comment: the terminology below differs from that defined by ITU-T
   documents (e.g., G.810, "Definitions and terminology for
   synchronization networks" and I.356, "B-ISDN ATM layer cell transfer
   performance"), but is consistent with the IPPM Framework document.
   In general, these differences derive from the different backgrounds;
   the ITU-T documents historically have a telephony origin, while the
   authors of this document (and the Framework) have a computer systems
   background.  Although the terms defined below have no direct
   equivalent in the ITU-T definitions, after our definitions we will
   provide a rough mapping.  However, note one potential confusion: our
   definition of "clock" is the computer operating systems definition
   denoting a time-of-day clock, while the ITU-T definition of clock
   denotes a frequency reference.}

{コメント: 以下の用語は、ITU-Tドキュメント(例えば、G.810と「同期ネットワークのための定義と用語」とI.356、「B-ISDN ATM層のセル転送性能」)によって定義されたそれと異なっていますが、IPPM Frameworkドキュメントと一致しています。 一般に、これらの違いが異なったバックグラウンドに由来しています。 ITU-Tドキュメントには、電話の起源が歴史的にあります、このドキュメント(そして、Framework)の作者では、コンピュータ・システムバックグラウンドがありますが。 以下で定義された用語はITU-T定義におけるどんなダイレクト同等物も持っていませんが、私たちの定義の後に、私たちは荒いマッピングを提供するつもりです。 しかしながら、1回の潜在的混乱に注意してください: 私たちの「時計」の定義は時刻時計を指示するコンピュータオペレーティングシステム定義です、時計のITU-T定義が頻度参照を指示しますが。}

   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つの異なりましたが、関連する概念があります:

   synchronization*

同期*

        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.  {Comment: A rough
        ITU-T equivalent is "time error".}

同期は2個の時計が何時であるかに同意する範囲を測定します。 例えば、1人のホストの上の時計は5.4が2番目のホストの上の時計の前のmsecであるならそうするでしょうに。 コメント: 荒いITU-T同等物は「時間誤り」です。

Almes, et al.               Standards Track                     [Page 3]

RFC 2680          One Way Packet Loss Metric for IPPM     September 1999

Almes、他 IPPM1999年9月のメートル法の標準化過程[3ページ]RFC2680一方通行のパケット損失

   accuracy*

精度*

        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.  {Comment: A rough ITU-T equivalent is "time error from
        UTC".}

精度は与えられた時計がUTCに同意する範囲を測定します。 例えば、ホストの上の時計は27.1がUTCの後ろのmsecであるならそうするでしょうに。 コメント: 荒いITU-T同等物は「UTCからの時間誤り」です。

   resolution*

解決*

        Resolution measures the precision of a given clock.  For
        example, the clock on an old Unix host might advance only once
        every 10 msec, and thus have a resolution of only 10 msec.
        {Comment: A very rough ITU-T equivalent is "sampling period".}

決議は与えられた時計の精度を測定します。 例えば、年取ったUnixホストの上の時計は、かつてだけのあらゆる10msecを進めて、その結果、10msecだけの解決を持っているかもしれません。 コメント: 非常に荒いITU-T同等物は「サンプリング周期」です。

   skew*

斜行*

        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.  {Comment: A rough ITU-T equivalent is "time
        drift".}

斜行は時間がある精度、または同期の変化を測定します。 例えば、与えられたホストの上の時計は、1時間単位で1.3msecを獲得して、その結果、ひところ、UTCの後ろの27.1msecであるかもしれなく、唯一の25.8は1時間後のmsecです。 この場合、私たちは、UTCに比例して与えられたホストの時計には1.3の斜行が毎時のmsecにあると言います。UTCは精度を脅かします。 また、私たちは別の時計に比例して1個の時計の斜行について話すかもしれません。時計は同期を脅かします。 コメント: 荒いITU-T同等物は「時間ドリフト」です。

2. A Singleton Definition for One-way Packet Loss

2. 片道パケット損失のためのシングルトンDefinition

2.1. Metric Name:

2.1. メートル法の名前:

      Type-P-One-way-Packet-Loss

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-One-way-Packet-Loss is either a zero
   (signifying successful transmission of the packet) or a one
   (signifying loss).

Type-Pの片道パケットの損失の値は、ゼロ(パケットのうまくいっているトランスミッションを意味する)か1つ(損失を意味して)のどちらかです。

Almes, et al.               Standards Track                     [Page 4]

RFC 2680          One Way Packet Loss Metric for IPPM     September 1999

Almes、他 IPPM1999年9月のメートル法の標準化過程[4ページ]RFC2680一方通行のパケット損失

2.4. Definition:

2.4. 定義:

   >>The *Type-P-One-way-Packet-Loss* from Src to Dst at T is 0<< means
   that Src sent the first bit of a Type-P packet to Dst at wire-time* T
   and that Dst received that packet.

TのSrcからDstまでの*タイプの>>P片道のパケット損失*はSrcがワイヤ時間*TでDstへのType-Pパケットの最初のビットを送った0つの<<手段です、そして、そのDstはそのパケットを受けました。

   >>The *Type-P-One-way-Packet-Loss* from Src to Dst at T is 1<< means
   that Src sent the first bit of a type-P packet to Dst at wire-time T
   and that Dst did not receive that packet.

TのSrcからDstまでの*タイプの>>P片道のパケット損失*はSrcがワイヤ時間TでDstへのPをタイプしているパケットの最初のビットを送った1つの<<手段です、そして、そのDstはそのパケットを受けませんでした。

2.5. Discussion:

2.5. 議論:

   Thus, Type-P-One-way-Packet-Loss is 0 exactly when Type-P-One-way-
   Delay is a finite value, and it is 1 exactly when Type-P-One-way-
   Delay is undefined.

ちょうどType-P片道の遅れが有限値であるときに、したがって、Type-Pの片道パケットの損失は0です、そして、ちょうどType-P片道の遅れが未定義であるときに、それは1です。

   The following issues are likely to come up in practice:

以下の問題は実際には来そうです:

   +  A given methodology will have to include a way to distinguish
      between a packet loss and a very large (but finite) delay.  As
      noted by Mahdavi and Paxson [3], simple upper bounds (such as the
      255 seconds theoretical upper bound on the lifetimes of IP
      packets [4]) 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, there
      may be no harm in treating a large delay as packet loss.  An audio
      playback packet, for example, that arrives only after the playback
      point may as well have been lost.}

+ 与えられた方法論はパケット損失を見分ける方法と非常に大きくて(有限)の遅れを含まなければならないでしょう。 Mahdaviとパクソン[3]、簡単な上限で注意される、(255がIPパケット[4])の生涯理論上の上限を後援するとき、そのようなものを使用できましたが、パケット生存期間の理解を含む良い工学が実際には必要でしょう。 {コメント: 大きい遅れをパケット損失として扱うのにおいて害が全くこれらの測定基準の多くの応用のためにないかもしれないことに注意してください。 例えば再生ポイントの後にだけ到着するオーディオ再生パケットは失われるほうがよいです。}

   +  If the packet arrives, but is corrupted, then it is counted as
      lost.  {Comment: one is tempted to count the packet as received
      since corruption and packet loss are related but distinct
      phenomena.  If the IP header is corrupted, however, one cannot be
      sure about the source or destination IP addresses and is thus on
      shaky grounds about knowing that the corrupted received packet
      corresponds to a given sent test packet.  Similarly, if other
      parts of the packet needed by the methodology to know that the
      corrupted received packet corresponds to a given sent test packet,
      then such a packet would have to be counted as lost.  Counting
      these packets as lost but packet with corruption in other parts of
      the packet as not lost would be inconsistent.}

+はパケットであるなら到着しますが、崩壊して、次に、それは失われているように数えられます。 {コメント: 1つが不正とパケット損失が関連しますが、異なった現象であるので受け取るようにパケットを数えるように誘惑されます。 IPヘッダーが買収されるなら、しかしながら、1つは、IPが演説するソースか目的地に関して確かであるはずがなく、その結果、崩壊が受信されたのを知ることに関する不安定な根拠では、パケットが与えられた送られたテストパケットに対応しているということです。 同様に、パケットの他の一部が、方法論で崩壊した容認されたパケットが与えられた送られたテストパケットに対応するのを知る必要があるなら、そのようなパケットは失われているように数えられなければならないでしょうに。 不正がパケットの他の一部にある状態で失われていないように無くなっているこれらの同じくらいパケットにもかかわらず、パケットを数えるのは矛盾しているでしょう。}

   +  If the packet is duplicated along the path (or paths) so that
      multiple non-corrupt copies arrive at the destination, then the
      packet is counted as received.

パケットであるなら経路(または、経路)に沿って+がコピーされるので、複数の非不正なコピーが目的地に到着して、次に、パケットは受け取るように数えられます。

   +  If the packet is fragmented and if, for whatever reason,
      reassembly does not occur, then the packet will be deemed lost.

パケットであり、断片化されて、再アセンブリがいかなる理由でも現れないなら、+はそうであり、次に、パケットは無くなると考えられるでしょう。

Almes, et al.               Standards Track                     [Page 5]

RFC 2680          One Way Packet Loss Metric for IPPM     September 1999

Almes、他 IPPM1999年9月のメートル法の標準化過程[5ページ]RFC2680一方通行のパケット損失

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, one possible methodology would proceed
   as follows:

一般に、与えられたType-Pに関して、1つの可能な方法論が以下の通り続くでしょう:

   +  Arrange that Src and Dst have clocks that are synchronized with
      each other.  The degree of synchronization is a parameter of the
      methodology, and depends on the threshold used to determine loss
      (see below).

+はそのSrcをアレンジします、そして、Dstは互いに連動する時計を持っています。 同期の度合いは、方法論のパラメタであり、損失を決定するのに使用される敷居に依存します(以下を見てください)。

   +  At the Src host, select Src and Dst IP addresses, and form a test
      packet of Type-P with these addresses.

+ Srcホスト、選んだSrc、Dst IPアドレス、および用紙のこれらのアドレスがあるType-Pのテストパケット。

   +  At the Dst host, arrange to receive the packet.

+、Dstホストでは、パケットを受けるように手配してください。

   +  At the Src host, place a timestamp in the prepared Type-P packet,
      and send it towards Dst.

+、Srcホストでは、準備されたType-Pパケットにタイムスタンプを置いてください、そして、Dstに向かってそれを送ってください。

   +  If the packet arrives within a reasonable period of time, the one-
      way packet-loss is taken to be zero.

+はパケットであるなら適正な期間、ゼロになるようにパケット損失を取る1つの方法の中で到着します。

   +  If the packet fails to arrive within a reasonable period of time,
      the one-way packet-loss is taken to be one.  Note that the
      threshold of "reasonable" here is a parameter of the methodology.

+はパケットであるなら適正な期間以内に到着しないで、1になるように片道パケット損失を取ります。 ここで「妥当」の敷居が方法論のパラメタであることに注意してください。

      {Comment: The definition of reasonable is intentionally vague, and
      is intended to indicate a value "Th" so large that any value in
      the closed interval [Th-delta, Th+delta] is an equivalent
      threshold for loss.  Here, delta encompasses all error in clock
      synchronization along the measured path.  If there is a single
      value after which the packet must be counted as lost, then we
      reintroduce the need for a degree of clock synchronization similar
      to that needed for one-way delay.  Therefore, if a measure of
      packet loss parameterized by a specific non-huge "reasonable"
      time-out value is needed, one can always measure one-way delay and
      see what percentage of packets from a given stream exceed a given
      time-out value.}

{コメント: 妥当の定義が故意にあいまいであり、何かが閉じている間隔で評価するとても大きい値の“Th"を示すことを意図する、[第-、デルタ、Th+デルタ] 同等な敷居が損失でありますか? ここに、デルタは測定経路に沿った時計同期におけるすべての誤りを成就します。 失われているようにパケットを数えなければならないただ一つの値があれば、私たちは片道遅れに必要であるそれと同様の時計同期の1度の必要性に再紹介します。 したがって、特定の非巨大な「妥当な」タイムアウト値でparameterizedされたパケット損失の手段が必要であるなら、人は、いつも片道遅れを測定して、与えられた流れからの何パーセントのパケットが与えられたタイムアウト値を超えているかを見ることができます。}

   Issues such as the packet format, the means by which Dst knows when
   to expect the test packet, and the means by which Src and Dst are
   synchronized are outside the scope of this document.  {Comment: We
   plan to document elsewhere our own work in describing such more
   detailed implementation techniques and we encourage others to as
   well.}

このドキュメントの範囲の外にパケット・フォーマットや、Dstがいつテストパケットを予想するかを知っている手段や、SrcとDstが連動する手段などの問題があります。 : 私たちが、私たち自身のが働いているほかの場所にそのようなより詳細な実現のテクニックについて説明する際に記録するのを計画して、また、他のものを奨励するコメント。

Almes, et al.               Standards Track                     [Page 6]

RFC 2680          One Way Packet Loss Metric for IPPM     September 1999

Almes、他 IPPM1999年9月のメートル法の標準化過程[6ページ]RFC2680一方通行のパケット損失

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.

どんな特定の測定方法の記述も誤りか不確実性の様々な源の会計学と分析を含むべきです。 Frameworkドキュメントはこのポイントの上で一般的な指導を提供します。

   For loss, there are three sources of error:

損失によって、誤りの3つの源があります:

   +  Synchronization between clocks on Src and Dst.

+ SrcとDstの上の時計の間の同期。

   +  The packet-loss threshold (which is related to the synchronization
      between clocks).

+ パケット損失敷居(時計の間の同期に関連します)。

   +  Resource limits in the network interface or software on the
      receiving instrument.

+ ネットワーク・インターフェースのリソース限界か受信器具の上のソフトウェア。

   The first two sources are interrelated and could result in a test
   packet with finite delay being reported as lost.  Type-P-One-way-
   Packet-Loss is 0 if the test packet does not arrive, or if it does
   arrive and the difference between Src timestamp and Dst timestamp is
   greater than the "reasonable period of time", or loss threshold.  If
   the clocks are not sufficiently synchronized, the loss threshold may
   not be "reasonable" - the packet may take much less time to arrive
   than its Src timestamp indicates.  Similarly, if the loss threshold
   is set too low, then many packets may be counted as lost.  The loss
   threshold must be high enough, and the clocks synchronized well
   enough so that a packet that arrives is rarely counted as lost.  (See
   the discussions in the previous two sections.)

最初の2つのソースが、相関的であり、有限遅れが失われているように報告されている状態で、テストパケットをもたらすことができました。 タイプP片道、-テストパケットが到着しないか、または到着するならパケット損失が0であり、SrcタイムスタンプとDstタイムスタンプの違いは「適正な期間」、または損失敷居より大きいです。 時計が十分連動しないなら、損失敷居は「妥当でないかもしれません」--まして、パケットは、到着するにはSrcタイムスタンプが示すより時間がかかるかもしれません。 同様に、損失敷居があまりに低く設定されるなら、多くのパケットが失われているように数えられるかもしれません。 損失敷居が十分高くなければならなく、時計が十分よく連動したので、到着するパケットは失われているようにめったに数えられません。 (前の2つのセクションの議論を見てください。)

   Since the sensitivity of packet loss measurement to lack of clock
   synchronization is less than for delay, we refer the reader to the
   treatment of synchronization errors in the One-way Delay metric [2]
   for more details.

以来、時計同期の不足へのパケット損失測定の感度は私たちが遅れほどその他の詳細のためのOne-道のDelayのメートル法の[2]での同期誤りの処理に読者を差し向けないという、ことです。

   The last source of error, resource limits, cause the packet to be
   dropped by the measurement instrument, and counted as lost when in
   fact the network delivered the packet in reasonable time.

誤りの最後の源、リソース限界は、事実上、ネットワークが妥当な時間でパケットを届けたとき、失われているようにパケットが測定器具によって落とされて、数えられることを引き起こします。

   The measurement instruments should be calibrated such that the loss
   threshold is reasonable for application of the metrics and the clocks
   are synchronized enough so the loss threshold remains reasonable.

測定基準の応用に、測定器具が較正されるべきであるので、損失敷居は妥当であり、時計が十分連動するので、損失敷居は妥当なままです。

   In addition, the instruments should be checked to ensure the that the
   possibility a packet arrives at the network interface, but is lost
   due to congestion on the interface or to other resource exhaustion
   (e.g., buffers) on the instrument is low.

さらに、器具が確実にするためにチェックされるべきである、しかし、パケットがネットワークに到着する可能性が連結するのがインタフェースにおける混雑のため失われているか、または他のリソースに、器具における疲労困憊(例えば、バッファ)は低いです。

Almes, et al.               Standards Track                     [Page 7]

RFC 2680          One Way Packet Loss Metric for IPPM     September 1999

Almes、他 IPPM1999年9月のメートル法の標準化過程[7ページ]RFC2680一方通行のパケット損失

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: Type-P of the test
   packets, the loss threshold, instrument 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つの項目を提示します: テストパケットによって横断されたテストパケット、損失敷居、器具較正、および経路のタイプ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-One-way-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. 損失敷居

   The threshold (or methodology to distinguish) between a large finite
   delay and loss MUST be reported.

大きい有限遅れと損失の間の敷居(または、区別する方法論)を報告しなければなりません。

2.8.3. Calibration results

2.8.3. 較正結果

   The degree of synchronization between the Src and Dst clocks MUST be
   reported.  If possible, possibility that a test packet that arrives
   at the Dst network interface is reported as lost due to resource
   exhaustion on Dst SHOULD be reported.

SrcとDst時計の間の同期の度合いを報告しなければなりません。 Dst SHOULDにおけるリソース疲労困憊のため失われて、ネットワーク・インターフェースが報告されるDstに到着するテストパケットが報告されるできれば可能性。

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.  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, 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,

最終的に、経路はパケットでSHOULDを横断しました。可能であるなら、報告されてください。 一般に、与えられたパケットがネットワークを通して取る正確な経路を知るのは非実用的です。 正確な経路は短いか安定した経路のあるType-Pで知られているかもしれません。 Type-PがIPヘッダーに記録的なルート(または、ゆるい送信元経路)オプションを含んで、経路が十分短く、経路のすべてのルータ*が記録的で(自由なソース)のルートを支えると、経路は正確に記録されるでしょう。 または、ルートが十分短くなければならないので、これは非実用的です、ルータが支持しない多く、(構成されない、)、ルートを記録してください。そうすれば、この特徴の使用はしばしば人工的によくある例処理からパケットを取り除くことによって観測された性能を悪化させるでしょう。 しかしながら、部分的な情報はまだ貴重な文脈です。 例えば、ホストが2個のリンク*を選ぶことができるなら(したがって、2はSrcからDstまでルートを切り離します)、使用される初期のリンクは貴重な文脈です。 例えば、MeritのNetNowセットアップで以下について論評してください。

Almes, et al.               Standards Track                     [Page 8]

RFC 2680          One Way Packet Loss Metric for IPPM     September 1999

Almes、他 IPPM1999年9月のメートル法の標準化過程[8ページ]RFC2680一方通行のパケット損失

   a Src on one NAP can reach a Dst on another NAP by either of several
   different backbone networks.}

1NAPの上のSrcはいくつかの異なった背骨ネットワークのどちらかで別のNAPの上のDstに達することができます。

3. A Definition for Samples of One-way Packet Loss

3. 片道パケット損失のサンプルのための定義

   Given the singleton metric Type-P-One-way-Packet-Loss, 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-One-way-Packet-Loss-Poisson-Stream

タイプのP片道パケット損失ポアソンの流れ

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、時間。

   +  L, either a zero or a one

+ L(ゼロか1つのどちらか)

Almes, et al.               Standards Track                     [Page 9]

RFC 2680          One Way Packet Loss Metric for IPPM     September 1999

Almes、他 IPPM1999年9月のメートル法の標準化過程[9ページ]RFC2680一方通行のパケット損失

   The values of T in the sequence are monotonic increasing.  Note that
   T would be a valid parameter to Type-P-One-way-Packet-Loss, and that
   L would be a valid value of Type-P-One-way-Packet-Loss.

系列のTの値は単調な増加です。 TがType-Pの片道パケットの損失への有効なパラメタであるだろう、Lが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-One-way-Packet-Loss at
   this time.  The value of the sample is the sequence made up of the
   resulting <time, loss> 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.}

極端に注意する以外に、私たちは明確にλの値を抑制しません。 レートは大き過ぎて、次に、測定交通がネットワークを混乱させるということであるかどうか、そして、原因混雑自体。 レートがわずか過ぎるなら、あなたはおもしろいネットワークの振舞いを得ないかもしれません。 記録する: 私たちが経験を予想するコメント、および提案、ほかの場所の「最も良い現在の実務」ドキュメントに終わるλ。

   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.  The Poisson process is used
   to schedule the delay measurements.  The test packets will generally
   not arrive at Dst according to a Poisson distribution, since they are
   influenced by the network.

サンプルは、ともに、自己同期の効果を避けて、また、統計的にできるだけ不遍であることのサンプルを得るためにポアソン過程で定義されます。 ポアソン過程は、遅れ測定の計画をするのに使用されます。 ポアソン分布に従って、一般に、テストパケットはDstに到着しないでしょう、それらがネットワークによって影響を及ぼされるので。

   {Comment: there is, of course, no claim that real Internet traffic
   arrives according to a Poisson arrival process.

コメント: もちろん、ポアソン到着の過程に従って本当のインターネットトラフィックが到着するというクレームが全くありません。

   It is important to note that, in contrast to this metric, loss rates
   observed by transport connections do not reflect unbiased samples.
   For example, TCP transmissions both (1) occur in bursts, which can

これと対照して、メートル法です、輸送の接続によって観測された損失率が不遍のサンプルを反映しないことに注意するのは重要です。 例えば、TCPトランスミッション、(1)が起こる両方(そうすることができる)がはち切れます。

Almes, et al.               Standards Track                    [Page 10]

RFC 2680          One Way Packet Loss Metric for IPPM     September 1999

Almes、他 IPPM1999年9月のメートル法の標準化過程[10ページ]RFC2680一方通行のパケット損失

   induce loss due to the burst volume that would not otherwise have
   been observed, and (2) adapt their transmission rate in an attempt to
   minimize the loss rate observed by the connection.}

(2) 別の方法で観測されていない炸裂量による損失を引き起こしてください、そして、接続によって観測された損失率を最小にする試みにおけるそれらの通信速度を適合させてください。

   All the singleton Type-P-One-way-Packet-Loss 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-One-way-Packet-Loss-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-One-way-Packet-Loss metric.

+ 単独個体のType- Pの片道パケットの損失で既にメートル法でされた方法論議論。

   Care must be given to correctly handle out-of-order arrival of test
   packets; it is possible that the Src could send one test packet at
   TS[i], then send a second one (later) at TS[i+1], while the Dst could
   receive the second test packet at TR[i+1], and then receive the first
   one (later) at TR[i].

正しくテストパケットの不適切な到着を扱うために注意を与えなければなりません。 Srcが1つのテストパケットをTS[i]に送って、次に、2番目の1つに(後で)TS[i+1]に行かせるかもしれないのは、可能です、Dstが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
   arrival process of the wire-times of the sending of the test packets.
   Problems with this process could be caused by several things,
   including problems with the pseudo-random number techniques used to
   generate the Poisson arrival process.  The Framework document shows
   how to use the Anderson-Darling test verify the accuracy of the
   Poisson process over small time frames.  {Comment: The goal is to
   ensure that the test packets are sent "close enough" to a Poisson
   schedule, and avoid periodic behavior.}

サンプルを作る単独個体値を測定するのに使われる方法に関連している誤りと不明確なことの源に加えて、テストパケットの発信のワイヤ倍のポアソン到着の過程の精度を分析するために注意を与えなければなりません。 この過程に関する問題は数個のものによって引き起こされる場合がありました、ポアソン到着の過程を発生させるのに使用される擬似乱数のテクニックに関する問題を含んでいて。 確かめるドキュメントがどうアンダーソン-最愛の人テストを使用するかにポアソンの精度を示すFrameworkは小さい時間枠の上で処理します。 コメント: 目標はテストパケットがポアソンスケジュールの「十分近く」という送って、ことであり、周期行動を避けるのを保証することです。

3.8. Reporting the metric:

3.8. メートル法を報告します:

   The calibration and context for the underlying singletons MUST be
   reported along with the stream.  (See "Reporting the metric" for
   Type-P-One-way-Packet-Loss.)

流れと共に基本的な単独個体のための較正と文脈を報告しなければなりません。 (Type-Pの片道パケットの損失での「メートル法を報告します」を見てください。)

Almes, et al.               Standards Track                    [Page 11]

RFC 2680          One Way Packet Loss Metric for IPPM     September 1999

Almes、他 IPPM1999年9月のメートル法の標準化過程[11ページ]RFC2680一方通行のパケット損失

4. Some Statistics Definitions for One-way Packet Loss

4. 片道パケット損失のためのいくつかの統計定義

   Given the sample metric Type-P-One-way-Packet-Loss-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-One-way-Packet-Loss-Average

4.1. P片道パケット損失平均をタイプしてください。

   Given a Type-P-One-way-Packet-Loss-Poisson-Stream, the average of all
   the L values in the Stream.  In addition, the Type-P-One-way-Packet-
   Loss-Average is undefined if the sample is empty.

Type-Pの片道パケット損失ポアソンの流れ、StreamのすべてのL値の平均を与えます。 さらに、サンプルが空であるなら、Type-P片道のパケット損失平均は未定義です。

   Example: suppose we take a sample and the results are:

例: 私たちがサンプリングするか、そして、結果は以下の通りです。

      Stream1 = <
      <T1, 0>
      <T2, 0>
      <T3, 1>
      <T4, 0>
      <T5, 0>
      >

Stream1は<<T1、0><T2、0><T3、1><T4、0><T5、0>>と等しいです。

   Then the average would be 0.2.

そして、平均は0.2でしょう。

   Note that, since healthy Internet paths should be operating at loss
   rates below 1% (particularly if high delay-bandwidth products are to
   be sustained), the sample sizes needed might be larger than one would
   like.  Thus, for example, if one wants to discriminate between
   various fractions of 1% over one-minute periods, then several hundred
   samples per minute might be needed.  This would result in larger
   values of lambda than one would ordinarily want.

健康なインターネット経路が損失率で1%未満を操作するべきであるので(高い遅れ帯域幅生成物が特に持続することであるなら)サイズが必要としたサンプルが人が好きであるだろうというよりも大きいかもしれないことに注意してください。 このようにして、そして、例えば、人が1分の期間、1%の様々な何分の一を区別したいなら、1分あたり数100個のサンプルが必要であるかもしれません。 これはλの通常、人が欲しいだろうより大きい値をもたらすでしょう。

   Note that although the loss threshold should be set such that any
   errors in loss are not significant, if the possibility that a packet
   which arrived is counted as lost due to resource exhaustion is
   significant compared to the loss rate of interest, Type-P-One-way-
   Packet-Loss-Average will be meaningless.

-損失敷居が損失におけるどんな誤りも重要でないようなものを設定することであるべきですが、損失率と興味があって、Type-P片道で比べて、到着したパケットがリソース疲労困憊のため失われているように数えられる可能性が重要であるならパケット損失平均が無意味になることに注意してください。

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.

インターネット測定値を行うと、セキュリティとプライバシーの問題の両方が提起されます。 このメモが測定基準の実現を指定しないので、それは直接インターネットで動くインターネットとアプリケーションのセキュリティに影響しません。 しかしながら、これらの測定基準の実現は心にセキュリティとプライバシーの問題をとどめていなければなりません。

Almes, et al.               Standards Track                    [Page 12]

RFC 2680          One Way Packet Loss Metric for IPPM     September 1999

Almes、他 IPPM1999年9月のメートル法の標準化過程[12ページ]RFC2680一方通行のパケット損失

   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. 承認

   Thanks are due to Matt Mathis for encouraging this work and for
   calling attention on so many occasions to the significance of packet
   loss.

感謝はこの仕事を奨励して、注意を訪問するためのとても多くの時のパケット損失の意味へのマット・マシスのためです。

   Thanks are due also to Vern Paxson for his valuable comments on early
   drafts, and to Garry Couch and Will Leland for several useful
   suggestions.

また、早めの草稿の彼の貴重なコメントのためのバーン・パクソン、ガルリCouch、およびウィル・リーランドにとって、感謝もいくつかの役に立つ提案のために当然です。

7. References

7. 参照

   [1]  Paxson, V.,  Almes,G., Mahdavi, J. and M. Mathis, "Framework for
        IP Performance Metrics", RFC 2330, May 1998.

[1] パクソン、V.、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]  Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
        Connectivity", RFC 2678, September 1999.

[3]Mahdavi、J.、および「測定の接続性のためのIPPM測定基準」、RFC2678、1999年9月対パクソン

Almes, et al.               Standards Track                    [Page 13]

RFC 2680          One Way Packet Loss Metric for IPPM     September 1999

Almes、他 IPPM1999年9月のメートル法の標準化過程[13ページ]RFC2680一方通行のパケット損失

   [4]  Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[4] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。

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

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

   [6]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
        9, RFC 2026, October 1996.

[6] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」

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 14]

RFC 2680          One Way Packet Loss Metric for IPPM     September 1999

Almes、他 IPPM1999年9月のメートル法の標準化過程[14ページ]RFC2680一方通行のパケット損失

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 15]

Almes、他 標準化過程[15ページ]