RFC4297 日本語訳

4297 Remote Direct Memory Access (RDMA) over IP Problem Statement. A.Romanow, J. Mogul, T. Talpey, S. Bailey. December 2005. (Format: TXT=48514 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                         A. Romanow
Request for Comments: 4297                                         Cisco
Category: Informational                                         J. Mogul
                                                                      HP
                                                               T. Talpey
                                                                  NetApp
                                                               S. Bailey
                                                               Sandburst
                                                           December 2005

Romanowがコメントのために要求するワーキンググループA.をネットワークでつないでください: 4297年のコクチマスカテゴリ: 情報のJ.のT.Talpey NetApp S.べイリーSandburst要人hp2005年12月

      Remote Direct Memory Access (RDMA) over IP Problem Statement

IP問題声明の上のリモートダイレクトメモリアクセス(RDMA)

Status of This Memo

このメモの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

Abstract

要約

   Overhead due to the movement of user data in the end-system network
   I/O processing path at high speeds is significant, and has limited
   the use of Internet protocols in interconnection networks, and the
   Internet itself -- especially where high bandwidth, low latency,
   and/or low overhead are required by the hosted application.

高速における終わり体系網入出力プロセシング・パスでの利用者データの動きによるオーバーヘッドは、重要であり、特に高帯域、低遅延、そして/または、低いオーバーヘッドが接待されたアプリケーションで必要であるところでインタコネクトネットワーク、およびインターネット自体でのインターネットプロトコルの使用を制限しました。

   This document examines this overhead, and addresses an architectural,
   IP-based "copy avoidance" solution for its elimination, by enabling
   Remote Direct Memory Access (RDMA).

このドキュメントは、このオーバーヘッドを調べて、除去のために建築していて、IPベースの「コピー回避」溶液を扱います、Remote Direct Memory Access(RDMA)を有効にすることによって。

Romanow, et al.              Informational                      [Page 1]

RFC 4297             RDMA over IP Problem Statement        December 2005

Romanow、他 IP問題声明2005年12月の間の情報[1ページ]のRFC4297RDMA

Table of Contents

目次

   1. Introduction ....................................................2
   2. The High Cost of Data Movement Operations in Network I/O ........4
      2.1. Copy avoidance improves processing overhead. ...............5
   3. Memory bandwidth is the root cause of the problem. ..............6
   4. High copy overhead is problematic for many key Internet
      applications. ...................................................8
   5. Copy Avoidance Techniques ......................................10
      5.1. A Conceptual Framework: DDP and RDMA ......................11
   6. Conclusions ....................................................12
   7. Security Considerations ........................................12
   8. Terminology ....................................................14
   9. Acknowledgements ...............................................14
   10. Informative References ........................................15

1. 序論…2 2. ネットワーク入出力における、データ動き操作の高い費用…4 2.1. コピー回避は処理オーバヘッドを向上させます。 ...............5 3. メモリ帯域幅は問題の根本的原因です。 ..............6 4. 多くの主要なインターネットアプリケーションに、高いコピーオーバーヘッドは問題が多いです。 ...................................................8 5. 回避のテクニックをコピーしてください…10 5.1. 概念の構成: DDPとRDMA…11 6. 結論…12 7. セキュリティ問題…12 8. 用語…14 9. 承認…14 10. 有益な参照…15

1.  Introduction

1. 序論

   This document considers the problem of high host processing overhead
   associated with the movement of user data to and from the network
   interface under high speed conditions.  This problem is often
   referred to as the "I/O bottleneck" [CT90].  More specifically, the
   source of high overhead that is of interest here is data movement
   operations, i.e., copying.  The throughput of a system may therefore
   be limited by the overhead of this copying.  This issue is not to be
   confused with TCP offload, which is not addressed here.  High speed
   refers to conditions where the network link speed is high, relative
   to the bandwidths of the host CPU and memory.  With today's computer
   systems, one Gigabit per second (Gbits/s) and over is considered high
   speed.

このドキュメントは、高いホスト処理オーバヘッドの問題がネットワーク・インターフェースと高速状態のネットワーク・インターフェースからの利用者データの動きに関連していると考えます。 この問題はしばしば「入出力ボトルネック」[CT90]と呼ばれます。 より明確に、ここで興味がある高いオーバーヘッドの源はデータ動き操作、すなわち、コピーです。 したがって、システムに関するスループットはこのコピーのオーバーヘッドによって制限されるかもしれません。 この問題はTCPオフロードに混乱しないことです。(それは、ここで扱われません)。 高速はネットワークリンク速度がホストCPUとメモリの帯域幅に比例して高いところと状態を呼びます。 今日のコンピュータ・システムで、2番目のより多くの(Gbits/s)あたり1Gigabitが高速であると考えられます。

   High costs associated with copying are an issue primarily for large
   scale systems.  Although smaller systems such as rack-mounted PCs and
   small workstations would benefit from a reduction in copying
   overhead, the benefit to smaller machines will be primarily in the
   next few years as they scale the amount of bandwidth they handle.
   Today, it is large system machines with high bandwidth feeds, usually
   multiprocessors and clusters, that are adversely affected by copying
   overhead.  Examples of such machines include all varieties of
   servers: database servers, storage servers, application servers for
   transaction processing, for e-commerce, and web serving, content
   distribution, video distribution, backups, data mining and decision
   support, and scientific computing.

コピーに関連している高いコストは主として大規模システムのための問題です。ラックマウントされたPCや小さいワークステーションなどの、より小さいシステムはオーバーヘッドをコピーする際に減少の利益を得るでしょうが、それらが扱う帯域幅の量をスケーリングするように、より小さいマシンへの利益が主としてこの数年間であるでしょう。 今日それが高帯域給送、通常マルチプロセッサ、およびクラスタがある大規模システムマシンである、それは、オーバーヘッドをコピーすることによって、悪影響を受けます。 そのようなマシンに関する例はすべての種類のサーバを含んでいます: データベースサーバー、ストレージサーバ、電子商取引、ウェブ給仕、満足している分配、ビデオ分配、バックアップ、データマイニング、および意志決定支援のためのトランザクション処理のためのアプリケーション・サーバー、および科学計算。

   Note that such servers almost exclusively service many concurrent
   sessions (transport connections), which, in aggregate, are
   responsible for > 1 Gbits/s of communication.  Nonetheless, the cost

そのようなサーバが多くの同時発生のセッション(輸送の接続)を専ら修理することに注意してください。(集合では、セッションはコミュニケーションの>1Gbits/sに原因となります)。 それにもかかわらず、費用

Romanow, et al.              Informational                      [Page 2]

RFC 4297             RDMA over IP Problem Statement        December 2005

Romanow、他 IP問題声明2005年12月の間の情報[2ページ]のRFC4297RDMA

   of copying overhead for a particular load is the same whether from
   few or many sessions.

コピーでは、わずかか多くのセッションにかかわらず特定の負荷のためのオーバーヘッドは同じです。

   The I/O bottleneck, and the role of data movement operations, have
   been widely studied in research and industry over the last
   approximately 14 years, and we draw freely on these results.
   Historically, the I/O bottleneck has received attention whenever new
   networking technology has substantially increased line rates: 100
   Megabit per second (Mbits/s) Fast Ethernet and Fibre Distributed Data
   Interface [FDDI], 155 Mbits/s Asynchronous Transfer Mode [ATM], 1
   Gbits/s Ethernet.  In earlier speed transitions, the availability of
   memory bandwidth allowed the I/O bottleneck issue to be deferred.
   Now however, this is no longer the case.  While the I/O problem is
   significant at 1 Gbits/s, it is the introduction of 10 Gbits/s
   Ethernet which is motivating an upsurge of activity in industry and
   research [IB, VI, CGY01, Ma02, MAF+02].

ここおよそ14年間、入出力ボトルネック、およびデータ動き操作の役割は研究と産業で広く研究されています、そして、私たちは自由にこれらの結果を利用します。 新しいネットワーク・テクノロジーがかなりライン料率を増強したときはいつも、歴史的に、入出力ボトルネックは配慮を受けました: 2番目の(メガビット/s)のファースト・イーサネットとFibre Distributed Data Interface[FDDI]、155メガビット/s Asynchronous Transfer Mode[ATM](1つのGbits/sイーサネット)あたりの100メガビット。 以前の速度変遷では、メモリ帯域幅の有用性で、入出力ボトルネック問題は据え置きました。 しかしながら、現在、これはもうそうではありません。 入出力問題は1Gbits/sで重要ですが、それは産業と研究[IB、VI、CGY01、Ma02、MAF+02]における、活動の盛り上がりを動機づけている10のGbits/sイーサネットの導入です。

   Because of high overhead of end-host processing in current
   implementations, the TCP/IP protocol stack is not used for high speed
   transfer.  Instead, special purpose network fabrics, using a
   technology generally known as Remote Direct Memory Access (RDMA),
   have been developed and are widely used.  RDMA is a set of mechanisms
   that allow the network adapter, under control of the application, to
   steer data directly into and out of application buffers.  Examples of
   such interconnection fabrics include Fibre Channel [FIBRE] for block
   storage transfer, Virtual Interface Architecture [VI] for database
   clusters, and Infiniband [IB], Compaq Servernet [SRVNET], and
   Quadrics [QUAD] for System Area Networks.  These link level
   technologies limit application scaling in both distance and size,
   meaning that the number of nodes cannot be arbitrarily large.

現在の実装における、終わりホスト・プロセッシングの高いオーバーヘッドのために、TCP/IPプロトコル・スタックは高速転送に使用されません。 一般に、Remote Direct Memory Access(RDMA)として知られている技術を使用して、専用ネットワーク骨組みは、代わりに、開発されて、広く使用されます。 RDMAは、バッファの中と、そして、直接アプリケーションバッファからデータを導くためにはアプリケーションのコントロールの下でネットワークアダプターを許容する1セットのメカニズムです。 そのようなインタコネクト骨組みに関する例はブロックストレージ転送のためのFibre Channel[FIBRE]、データベースクラスタのためのVIアーキテクチャ[VI]、Infiniband[IB]、コンパックServernet[SRVNET]、およびSystem Area NetworksのためのQuadrics[QUAD]を含んでいます。 これらのリンク・レベル技術は距離とサイズの両方を計量するアプリケーションを制限します、ノードの数が任意に大きいはずがないことを意味して。

   This problem statement substantiates the claim that in network I/O
   processing, high overhead results from data movement operations,
   specifically copying; and that copy avoidance significantly decreases
   this processing overhead.  It describes when and why the high
   processing overheads occur, explains why the overhead is problematic,
   and points out which applications are most affected.

この問題声明は明確にコピーして、ネットワーク入出力処理では、高いオーバーヘッドがデータ動き操作から生じるというクレームを実体化します。 そして、そのコピー回避はこの処理オーバヘッドをかなり下げます。 それは、高い処理オーバヘッドがいつ、なぜ起こるかを説明して、オーバーヘッドがなぜ問題が多いかを説明して、どのアプリケーションが最も影響を受けるかを指摘します。

   The document goes on to discuss why the problem is relevant to the
   Internet and to Internet-based applications.  Applications that
   store, manage, and distribute the information of the Internet are
   well suited to applying the copy avoidance solution.  They will
   benefit by avoiding high processing overheads, which removes limits
   to the available scaling of tiered end-systems.  Copy avoidance also
   eliminates latency for these systems, which can further benefit
   effective distributed processing.

ドキュメントは、問題がなぜインターネットと、そして、インターネットを利用するアプリケーションに関連しているかと議論し続けます。 インターネットの情報を保存して、管理して、分配するアプリケーションがコピー回避対策を適用するのによく適しています。 彼らは高い処理オーバヘッドを避けることによって、利益を得るでしょう、また、どれがtieredエンドシステムコピー回避の利用可能なスケーリングへの限界を取り除くかがこれらのシステムのために潜在を根絶します。(さらに、システムは効果的な分散処理のためになることができます)。

Romanow, et al.              Informational                      [Page 3]

RFC 4297             RDMA over IP Problem Statement        December 2005

Romanow、他 IP問題声明2005年12月の間の情報[3ページ]のRFC4297RDMA

   In addition, this document introduces an architectural approach to
   solving the problem, which is developed in detail in [BT05].  It also
   discusses how the proposed technology may introduce security concerns
   and how they should be addressed.

さらに、このドキュメントは問題を解決するのに建築アプローチを紹介します。(問題は[BT05]に詳細に発生します)。 また、それは、提案された技術がどのように安全上の配慮を導入するかもしれないか、そして、それらがどのように扱われるべきであるかと議論します。

   Finally, this document includes a Terminology section to aid as a
   reference for several new terms introduced by RDMA.

最終的に、このドキュメントはRDMAによっていくつかの新学期の参照としての援助に取り入れられたTerminology部を含んでいます。

2.  The High Cost of Data Movement Operations in Network I/O

2. ネットワーク入出力における、データ動き操作の高い費用

   A wealth of data from research and industry shows that copying is
   responsible for substantial amounts of processing overhead.  It
   further shows that even in carefully implemented systems, eliminating
   copies significantly reduces the overhead, as referenced below.

研究と産業からの豊富なデータが、コピーはかなりの量の処理オーバヘッドに責任があるのを示します。 それは、コピーを排除すると慎重に実装しているシステムでさえオーバーヘッドが以下で参照をつけられるとしてかなり下げられるのをさらに示します。

   Clark et al. [CJRS89] in 1989 shows that TCP [Po81] overhead
   processing is attributable to both operating system costs (such as
   interrupts, context switches, process management, buffer management,
   timer management) and the costs associated with processing individual
   bytes (specifically, computing the checksum and moving data in
   memory).  They found that moving data in memory is the more important
   of the costs, and their experiments show that memory bandwidth is the
   greatest source of limitation.  In the data presented [CJRS89], 64%
   of the measured microsecond overhead was attributable to data
   touching operations, and 48% was accounted for by copying.  The
   system measured Berkeley TCP on a Sun-3/60 using 1460 Byte Ethernet
   packets.

クラーク他 1989年の[CJRS89]は、TCP[Po81]の頭上の処理にオペレーティングシステムコスト(中断、文脈スイッチ、工程管理、バッファ管理、タイマ管理などの)と個々のバイトを処理すると関連しているコスト(明確にメモリのチェックサムと感動的なデータを計算する)の両方に起因しているのを示します。 彼らは、コストでメモリの感動的なデータが、より重要であることがわかりました、そして、彼らの実験はメモリ帯域幅が制限の最大級の源であることを示します。 [CJRS89]が提示されたデータでは、頭上の測定マイクロセカンドの64%はデータの感動的な操作に起因していました、そして、48%は、コピーすることによって、占めました。 システムは1460のByteイーサネットパケットを使用するSun-3/60でバークレーTCPを測定しました。

   In a well-implemented system, copying can occur between the network
   interface and the kernel, and between the kernel and application
   buffers; there are two copies, each of which are two memory bus
   crossings, for read and write.  Although in certain circumstances it
   is possible to do better, usually two copies are required on receive.

よく実装しているシステムでは、コピーはネットワーク・インターフェースとカーネルの間と、そして、カーネルとアプリケーションバッファの間に起こることができます。 コピー2部があります。読書のための2つのメモリバス交差点です。それはそのそれぞれを書きます。 それが順調であるのに、通常、コピー2部が必要であることが可能である、ある事情で受信しますが、受信してください。

   Subsequent work has consistently shown the same phenomenon as the
   earlier Clark study.  A number of studies report results that data-
   touching operations, checksumming and data movement, dominate the
   processing costs for messages longer than 128 Bytes [BS96, CGY01,
   Ch96, CJRS89, DAPP93, KP96].  For smaller sized messages, per-packet
   overheads dominate [KP96, CGY01].

その後の仕事は一貫して以前のクラークの研究と同じ現象を示しました。 多くの研究がデータの感動的な操作(checksummingとデータ運動)がメッセージのために128Bytes[BS96、CGY01、Ch96、CJRS89、DAPP93、KP96]より長い間処理コストを支配しているという結果を報告します。 より小さい大きさで分けられたメッセージに関しては、1パケットあたりのオーバーヘッドは[KP96、CGY01]を支配しています。

   The percentage of overhead due to data-touching operations increases
   with packet size, since time spent on per-byte operations scales
   linearly with message size [KP96].  For example, Chu [Ch96] reported
   substantial per-byte latency costs as a percentage of total
   networking software costs for an MTU size packet on a SPARCstation/20

パケットサイズに従って、データを感動的な操作によるオーバーヘッドの割合は増加します、直線的に1バイトあたりの操作スケールにメッセージサイズ[KP96]と費やされた時間以来。 例えば、チュウ[Ch96]はMTUサイズパケットのためにソフトウェアコストをSPARCstation/20にネットワークでつなぐ全体に占める割合として1バイトあたりのかなりの潜在コストを報告しました。

Romanow, et al.              Informational                      [Page 4]

RFC 4297             RDMA over IP Problem Statement        December 2005

Romanow、他 IP問題声明2005年12月の間の情報[4ページ]のRFC4297RDMA

   running memory-to-memory TCP tests over networks with 3 different MTU
   sizes.  The percentage of total software costs attributable to
   per-byte operations were:

メモリからメモリへの実行しているTCPはネットワークの上で3つの異なったMTUサイズでテストします。 1バイトあたりの操作に起因する全体に占める割合ソフトウェアコストは以下の通りでした。

      1500 Byte Ethernet 18-25%
      4352 Byte FDDI     35-50%
      9180 Byte ATM      55-65%

4352年の18-25%のバイトのイーサネットのFDDIの9180年の35-50%のバイトの1500年のバイトの気圧55-65%

   Although many studies report results for data-touching operations,
   including checksumming and data movement together, much work has
   focused just on copying [BS96, Br99, Ch96, TK95].  For example,
   [KP96] reports results that separate processing times for checksum
   from data movement operations.  For the 1500 Byte Ethernet size, 20%
   of total processing overhead time is attributable to copying.  The
   study used 2 DECstations 5000/200 connected by an FDDI network.  (In
   this study, checksum accounts for 30% of the processing time.)

多くの研究がchecksummingとデータ運動を一緒に含むデータを感動的な操作のために結果を報告しますが、多くの仕事が、まさしく[BS96、Br99、Ch96、TK95]をコピーするのは焦点を合わせました。 例えば、[KP96]はチェックサムのためにデータ動き操作と処理時間を切り離す結果を報告します。 1500年のByteイーサネットサイズにおいて、20%の総処理オーバヘッド回はコピーに起因しています。 研究はFDDIネットワークによって接続された2DECstations5000/200を使用しました。 (この研究では、チェックサムは処理時間の30%を占めます。)

2.1.  Copy avoidance improves processing overhead.

2.1. コピー回避は処理オーバヘッドを向上させます。

   A number of studies show that eliminating copies substantially
   reduces overhead.  For example, results from copy-avoidance in the
   IO-Lite system [PDZ99], which aimed at improving web server
   performance, show a throughput increase of 43% over an optimized web
   server, and 137% improvement over an Apache server.  The system was
   implemented in a 4.4BSD-derived UNIX kernel, and the experiments used
   a server system based on a 333MHz Pentium II PC connected to a
   switched 100 Mbits/s Fast Ethernet.

多くの研究が、コピーを排除するのがかなり経費を削減するのを示します。 それは、ウェブサーバー性能を向上させるのを目的としました。例えば、IO-Liteシステム[PDZ99]におけるコピー回避からの結果は最適化されたウェブサーバー、およびアパッチサーバの上の137%の改良に43%のスループット増加を見せてまわります。システムは4.4BSDによって派生させられたUNIXカーネルで導入されました、そして、実験は100の切り換えられたメガビット/sファースト・イーサネットに接続された333MHzのPentium II PCに基づくサーバシステムを使用しました。

   There are many other examples where elimination of copying using a
   variety of different approaches showed significant improvement in
   system performance [CFF+94, DP93, EBBV95, KSZ95, TK95, Wa97].  We
   will discuss the results of one of these studies in detail in order
   to clarify the significant degree of improvement produced by copy
   avoidance [Ch02].

システム性能[CFF+94、DP93、EBBV95、KSZ95、TK95、Wa97]には他の多くの例がさまざまな異なるアプローチを使用することでコピーする除去がかなりの改善を示したところにあります。 私たちは、コピー回避[Ch02]で起こされた重要な度合いの改良をはっきりさせるために詳細にこれらの研究の1つの結果について議論するつもりです。

   Recent work by Chase et al. [CGY01], measuring CPU utilization, shows
   that avoiding copies reduces CPU time spent on data access from 24%
   to 15% at 370 Mbits/s for a 32 KBytes MTU using an AlphaStation
   XP1000 and a Myrinet adapter [BCF+95].  This is an absolute
   improvement of 9% due to copy avoidance.

チェイス他による近作 [CGY01](測定CPU使用率)は、コピーを避けると32KBytes MTUのために370メガビット/sでAlphaStation XP1000を使用することで24%から15%までのデータ・アクセスに費やされたCPU時間とMyrinetアダプターが減少するのを[BCF+95]示します。 これはコピー回避による9%の絶対改良です。

   The total CPU utilization was 35%, with data access accounting for
   24%.  Thus, the relative importance of reducing copies is 26%.  At
   370 Mbits/s, the system is not very heavily loaded.  The relative
   improvement in achievable bandwidth is 34%.  This is the improvement
   we would see if copy avoidance were added when the machine was
   saturated by network I/O.

総CPU使用率は24%のためのデータ・アクセス会計がある35%でした。 したがって、コピーを減少させる相対的な重要性は26%です。 370メガビット/sでは、システムはそれほど大いにロードされません。 達成可能な帯域幅での相対的な改良は34%です。 マシンがネットワーク入出力で飽和状態にされたとき、コピー回避が加えられたなら、これは私たちが見る改良です。

Romanow, et al.              Informational                      [Page 5]

RFC 4297             RDMA over IP Problem Statement        December 2005

Romanow、他 IP問題声明2005年12月の間の情報[5ページ]のRFC4297RDMA

   Note that improvement from the optimization becomes more important if
   the overhead it targets is a larger share of the total cost.  This is
   what happens if other sources of overhead, such as checksumming, are
   eliminated.  In [CGY01], after removing checksum overhead, copy
   avoidance reduces CPU utilization from 26% to 10%.  This is a 16%
   absolute reduction, a 61% relative reduction, and a 160% relative
   improvement in achievable bandwidth.

最適化からの改良がそれが狙うオーバーヘッドが総費用の、より大きいシェアであるなら、より重要になることに注意してください。 これはchecksummingなどのオーバーヘッドの他の源が排除されるなら起こることです。 [CGY01]では、チェックサムオーバーヘッドを取り除いた後に、コピー回避はCPU使用率を26%から10%まで抑えます。 これは、16%の絶対減少と、61%の相対的な減少と、達成可能な帯域幅での160%の相対的な改良です。

   In fact, today's network interface hardware commonly offloads the
   checksum, which removes the other source of per-byte overhead.  They
   also coalesce interrupts to reduce per-packet costs.  Thus, today
   copying costs account for a relatively larger part of CPU utilization
   than previously, and therefore relatively more benefit is to be
   gained in reducing them.  (Of course this argument would be specious
   if the amount of overhead were insignificant, but it has been shown
   to be substantial.  [BS96, Br99, Ch96, KP96, TK95])

事実上、今日のネットワーク・インターフェースハードウェアは一般的にチェックサムを積み下ろします。(それは、1バイトあたりのオーバーヘッドのもう片方の源を取り外します)。 また、彼らは、1パケットあたりのコストを削減するために中断を合体させます。 したがって、今日コピーしているコストは以前によりCPU使用率の比較的かなりの部分を占めます、そして、したがって、比較的多くの利益はそれらを減少させる際に獲得することです。 (もちろん、オーバーヘッドの量がわずかであるなら、この議論はまことしやかでしょうにが、それは、実質的になるように示されました。 [BS96、Br99、Ch96、KP96、TK95])

3.  Memory bandwidth is the root cause of the problem.

3. メモリ帯域幅は問題の根本的原因です。

   Data movement operations are expensive because memory bandwidth is
   scarce relative to network bandwidth and CPU bandwidth [PAC+97].
   This trend existed in the past and is expected to continue into the
   future [HP97, STREAM], especially in large multiprocessor systems.

メモリ帯域幅がネットワーク回線容量とCPU帯域幅[PAC+97]に比例して不十分であるので、データ動き操作は高価です。 この傾向は、過去に存在して、将来に向けて存続すると予想されます[HP97、STREAM]、特に大きいマルチプロセッサシステムで。

   With copies crossing the bus twice per copy, network processing
   overhead is high whenever network bandwidth is large in comparison to
   CPU and memory bandwidths.  Generally, with today's end-systems, the
   effects are observable at network speeds over 1 Gbits/s.  In fact,
   with multiple bus crossings it is possible to see the bus bandwidth
   being the limiting factor for throughput.  This prevents such an
   end-system from simultaneously achieving full network bandwidth and
   full application performance.

コピー単位でコピーがバスに二度交差であっている中に、ネットワーク回線容量が比較でCPUとメモリ帯域幅に大きいときはいつも、ネットワーク処理オーバヘッドは高いです。 一般に、今日のエンドシステムで、効果は1以上のネットワーク速度Gbits/sで観察可能です。 事実上、複数のバス交差点では、バス帯域幅がスループットのための限定因子であると考えるのが可能です。 これは、そのようなエンドシステムが同時に完全なネットワーク回線容量と完全なアプリケーション性能を実現するのを防ぎます。

   A common question is whether an increase in CPU processing power
   alleviates the problem of high processing costs of network I/O.  The
   answer is no, it is the memory bandwidth that is the issue.  Faster
   CPUs do not help if the CPU spends most of its time waiting for
   memory [CGY01].

よくある質問はCPU処理能力の増加がネットワーク入出力の高い処理コストの問題を軽減するかどうかということです。 答えがノーである、それは問題であるメモリ帯域幅です。 CPUがメモリ[CGY01]を待っているのに時間の大部分を費やすなら、より速いCPUは役に立ちません。

   The widening gap between microprocessor performance and memory
   performance has long been a widely recognized and well-understood
   problem [PAC+97].  Hennessy [HP97] shows microprocessor performance
   grew from 1980-1998 at 60% per year, while the access time to DRAM
   improved at 10% per year, giving rise to an increasing "processor-
   memory performance gap".

長い間、マイクロプロセッサ性能とメモリ性能の拡大する格差は広く認識されて、よく理解されている問題[PAC+97]です。 ヘネシー[HP97]は、マイクロプロセッサ性能が1980年から1998年までの間1年あたり60%で成長したのを示します、DRAMへのアクセスタイムは1年あたり10%で向上しましたが、増加する「プロセッサメモリ性能ギャップ」をもたらして。

Romanow, et al.              Informational                      [Page 6]

RFC 4297             RDMA over IP Problem Statement        December 2005

Romanow、他 IP問題声明2005年12月の間の情報[6ページ]のRFC4297RDMA

   Another source of relevant data is the STREAM Benchmark Reference
   Information website, which provides information on the STREAM
   benchmark [STREAM].  The benchmark is a simple synthetic benchmark
   program that measures sustainable memory bandwidth (in MBytes/s) and
   the corresponding computation rate for simple vector kernels measured
   in MFLOPS.  The website tracks information on sustainable memory
   bandwidth for hundreds of machines and all major vendors.

関連データの別の源はSTREAM Benchmark Reference情報ウェブサイトです。(そのウェブサイトはSTREAMベンチマーク[STREAM]の情報を提供します)。 ベンチマークは、持続可能なメモリ帯域幅(MBytes/sの)を測定する簡単な合成のベンチマーク・プログラムとメガフロップスで測定された簡単なベクトルカーネルの対応する計算率です。ウェブサイトは何百台ものマシンとすべての主要なベンダーのために持続可能なメモリ帯域幅の情報を追跡します。

   Results show measured system performance statistics.  Processing
   performance from 1985-2001 increased at 50% per year on average, and
   sustainable memory bandwidth from 1975 to 2001 increased at 35% per
   year, on average, over all the systems measured.  A similar 15% per
   year lead of processing bandwidth over memory bandwidth shows up in
   another statistic, machine balance [Mc95], a measure of the relative
   rate of CPU to memory bandwidth (FLOPS/cycle) / (sustained memory
   ops/cycle) [STREAM].

結果は測定システム性能統計を示しています。 1985年から2001年までの間にすべてのシステムの上で1975年から2001年までの帯域幅が1年あたり35%で増強した平均して、持続可能なメモリで1年あたり50%で平均的に増強された処理能力は測定しました。 同様のメモリ帯域幅の上の処理帯域幅の年のリードあたり15%は別の統計値で現れます、マシンバランス[Mc95]、メモリ帯域幅(フロップス/サイクル)/(メモリオプアート/サイクルを支えます)[STREAM]へのCPUの相対的な料金の基準。

   Network bandwidth has been increasing about 10-fold roughly every 8
   years, which is a 40% per year growth rate.

ネットワーク回線容量は10倍のおよそあらゆる8年に関して増加しています。(年は年の成長率あたり40%です)。

   A typical example illustrates that the memory bandwidth compares
   unfavorably with link speed.  The STREAM benchmark shows that a
   modern uniprocessor PC, for example the 1.2 GHz Athlon in 2001, will
   move the data 3 times in doing a receive operation: once for the
   network interface to deposit the data in memory, and twice for the
   CPU to copy the data.  With 1 GBytes/s of memory bandwidth, meaning
   one read or one write, the machine could handle approximately 2.67
   Gbits/s of network bandwidth, one third the copy bandwidth.  But this
   assumes 100% utilization, which is not possible, and more importantly
   the machine would be totally consumed!  (A rule of thumb for
   databases is that 20% of the machine should be required to service
   I/O, leaving 80% for the database application.  And, the less, the
   better.)

典型的な例は、メモリ帯域幅がリンク速度で引けを取るのを例証します。 aをする際に3回動くベンチマークがそのa現代のuniprocessor PC、例えば、2001、意志での1.2ギガヘルツアスロンにデータを示すSTREAMは操作を受けます: ネットワークのための一度、連結して、メモリのデータを預けて、CPUは二度データをコピーしてください。 1で、メモリ帯域幅のGBytes/s、1つが読んだことを意味するか、または人が書いて、マシンはネットワーク回線容量(コピー帯域幅の1/3)のおよそ2.67Gbits/sを扱うかもしれません。 しかし、これは100%の利用を仮定します、そして、より重要に、マシンは完全に消費されます!(利用は可能ではありません)。 (データベースのための経験則はマシンの20%が入出力を修理するのに必要であるべきであるということです、80%をデータベースアプリケーションに残して。 そして、それほどより良くはありません。)

   In 2001, 1 Gbits/s links were common.  An application server may
   typically have two 1 Gbits/s connections: one connection backend to a
   storage server and one front-end, say for serving HTTP [FGM+99].
   Thus, the communications could use 2 Gbits/s.  In our typical
   example, the machine could handle 2.7 Gbits/s at its theoretical
   maximum while doing nothing else.  This means that the machine
   basically could not keep up with the communication demands in 2001;
   with the relative growth trends, the situation only gets worse.

2001、1では、Gbits/sリンクは一般的でした。 アプリケーション・サーバーには、2つの1Gbits/s接続が通常あるかもしれません: ストレージサーバへのある接続バックエンドとたとえば、HTTP[FGM+99]に役立つためのあるフロントエンド。 したがって、コミュニケーションは2Gbits/sを使用するかもしれません。 私たちの典型的な例では、マシンは他に何もをしている間、理論上の最大で2.7Gbits/sを扱うかもしれません。 これは、マシンが2001年に基本的にコミュニケーション要求について行くことができなかったことを意味します。 相対成長傾向で、状況は、より悪くなるだけです。

Romanow, et al.              Informational                      [Page 7]

RFC 4297             RDMA over IP Problem Statement        December 2005

Romanow、他 IP問題声明2005年12月の間の情報[7ページ]のRFC4297RDMA

4.  High copy overhead is problematic for many key Internet
    applications.

4. 多くの主要なインターネットアプリケーションに、高いコピーオーバーヘッドは問題が多いです。

   If a significant portion of resources on an application machine is
   consumed in network I/O rather than in application processing, it
   makes it difficult for the application to scale, i.e., to handle more
   clients, to offer more services.

アプリケーションマシンに関するリソースの重要な部分が手続きの経緯でというよりむしろネットワーク入出力で消費されるなら、それで、すなわち、アプリケーションが、より多くのクライアントを扱うために比例するのが、より多くのサービスを提供するために難しくなります。

   Several years ago the most affected applications were streaming
   multimedia, parallel file systems, and supercomputing on clusters
   [BS96].  In addition, today the applications that suffer from copying
   overhead are more central in Internet computing -- they store,
   manage, and distribute the information of the Internet and the
   enterprise.  They include database applications doing transaction
   processing, e-commerce, web serving, decision support, content
   distribution, video distribution, and backups.  Clusters are
   typically used for this category of application, since they have
   advantages of availability and scalability.

数年前に、最も影響を受けるアプリケーションは、ストリーミングのマルチメディアと、平行なファイルシステムと、クラスタ[BS96]の上にスーパー計算したことです。 さらに、今日、インターネットコンピューティングではオーバーヘッドをコピーするのに苦しむアプリケーションは、より主要です--それらは、インターネットと企業の情報を保存して、管理して、分配します。 彼らはトランザクション処理、電子商取引、ウェブ給仕、意志決定支援、満足している分配、ビデオ分配、およびバックアップをするデータベースアプリケーションを含んでいます。 それらには有用性とスケーラビリティの利点があるので、クラスタはアプリケーションのこのカテゴリに通常使用されます。

   Today these applications, which provide and manage Internet and
   corporate information, are typically run in data centers that are
   organized into three logical tiers.  One tier is typically a set of
   web servers connecting to the WAN.  The second tier is a set of
   application servers that run the specific applications usually on
   more powerful machines, and the third tier is backend databases.
   Physically, the first two tiers -- web server and application server
   -- are usually combined [Pi01].  For example, an e-commerce server
   communicates with a database server and with a customer site, or a
   content distribution server connects to a server farm, or an OLTP
   server connects to a database and a customer site.

今日、これらのアプリケーションであり、どれがインターネットと企業情報を提供して、管理して、あるかが3つの論理的な層の中に組織化されるデータセンターに通常立候補します。 通常、1つの層がWANに接続する1セットのウェブサーバーです。 2番目の層は通常、より強力なマシンに特定のアプリケーションを実行する1セットのアプリケーション・サーバーです、そして、3番目の層はバックエンドデータベースです。 物理的に、通常、最初の2つの層(ウェブサーバーとアプリケーション・サーバー)が結合されます[Pi01]。 例えば、電子商取引サーバがデータベースサーバーと顧客サイトで交信するか、満足している分配サーバがサーバー・ファームに接続するか、またはOLTPサーバはデータベースと顧客サイトに接続します。

   When network I/O uses too much memory bandwidth, performance on
   network paths between tiers can suffer.  (There might also be
   performance issues on Storage Area Network paths used either by the
   database tier or the application tier.)  The high overhead from
   network-related memory copies diverts system resources from other
   application processing.  It also can create bottlenecks that limit
   total system performance.

ネットワーク入出力があまりに多くのメモリ帯域幅を使用するとき、層の間のネットワーク経路に関する性能に苦しむことができます。 (また、性能問題がデータベース層かアプリケーション層によって使用されるストレージ・エリア・ネットワーク経路にあるかもしれません。) ネットワーク関連のメモリコピーからの高いオーバーヘッドは他の手続きの経緯からシステム資源を転換します。 また、それはトータル・システム性能を制限するボトルネックを作成できます。

   There is high motivation to maximize the processing capacity of each
   CPU because scaling by adding CPUs, one way or another, has
   drawbacks.  For example, adding CPUs to a multiprocessor will not
   necessarily help because a multiprocessor improves performance only
   when the memory bus has additional bandwidth to spare.  Clustering
   can add additional complexity to handling the applications.

いずれにしてもCPUを加えることによって比例するのにおいて欠点があるのでそれぞれのCPUの処理容量を最大にする高い動機があります。 例えば、メモリバスに割く追加帯域幅があるときだけ、マルチプロセッサが性能を向上させるので、マルチプロセッサにCPUを加えるのは必ず助けるというわけではないでしょう。 クラスタリングはアプリケーションを扱うのに追加複雑さを加えることができます。

   In order to scale a cluster or multiprocessor system, one must
   proportionately scale the interconnect bandwidth.  Interconnect

クラスタかマルチプロセッサシステムをスケーリングするために、内部連絡帯域幅を比例してスケーリングしなければなりません。 内部連絡

Romanow, et al.              Informational                      [Page 8]

RFC 4297             RDMA over IP Problem Statement        December 2005

Romanow、他 IP問題声明2005年12月の間の情報[8ページ]のRFC4297RDMA

   bandwidth governs the performance of communication-intensive parallel
   applications; if this (often expressed in terms of "bisection
   bandwidth") is too low, adding additional processors cannot improve
   system throughput.  Interconnect latency can also limit the
   performance of applications that frequently share data between
   processors.

帯域幅はコミュニケーション徹底的な平行なアプリケーションの性能を決定します。 これ(しばしば「二等分帯域幅」に関して言い表される)が低過ぎるなら、追加プロセッサを加える場合、システム・スループットを改良できません。 また、内部連絡潜在は頻繁にプロセッサの間のデータを共有するアプリケーションの性能を制限できます。

   So, excessive overheads on network paths in a "scalable" system both
   can require the use of more processors than optimal, and can reduce
   the marginal utility of those additional processors.

それで、システムの「スケーラブルな」両方のネットワーク経路の過度のオーバーヘッドは、最適であるより多くのプロセッサの使用を必要とすることができて、それらの追加プロセッサの限界効用を減少させることができます。

   Copy avoidance scales a machine upwards by removing at least two-
   thirds of the bus bandwidth load from the "very best" 1-copy (on
   receive) implementations, and removes at least 80% of the bandwidth
   overhead from the 2-copy implementations.

コピー回避が「最も良い」コピー1部から少なくともバス帯域幅荷重の2/3を取り除くことによって上向きにマシンをスケーリングする、(オンである、受信、)、実装、コピー2部の実装から帯域幅オーバーヘッドの少なくとも80%を取り除きます。

   The removal of bus bandwidth requirements, in turn, removes
   bottlenecks from the network processing path and increases the
   throughput of the machine.  On a machine with limited bus bandwidth,
   the advantages of removing this load is immediately evident, as the
   host can attain full network bandwidth.  Even on a machine with bus
   bandwidth adequate to sustain full network bandwidth, removal of bus
   bandwidth load serves to increase the availability of the machine for
   the processing of user applications, in some cases dramatically.

バス帯域幅要件の取り外しは、ネットワークプロセシング・パスからボトルネックを順番に取り除いて、マシンに関するスループットを増強します。 限られたバス帯域幅があるマシンでは、この負荷を取り除く利点はすぐに明白です、ホストが完全なネットワーク回線容量に達することができるとき。 バス帯域幅が完全なネットワーク回線容量を支えるために適切のマシンの上でさえ、バス帯域幅荷重の取り外しは、いくつかの場合における、ユーザアプリケーションの処理のためのマシンの有用性を劇的に増強するのに役立ちます。

   An example showing poor performance with copies and improved scaling
   with copy avoidance is illustrative.  The IO-Lite work [PDZ99] shows
   higher server throughput servicing more clients using a zero-copy
   system.  In an experiment designed to mimic real world web conditions
   by simulating the effect of TCP WAN connections on the server, the
   performance of 3 servers was compared.  One server was Apache,
   another was an optimized server called Flash, and the third was the
   Flash server running IO-Lite, called Flash-Lite with zero copy.  The
   measurement was of throughput in requests/second as a function of the
   number of slow background clients that could be served.  As the table
   shows, Flash-Lite has better throughput, especially as the number of
   clients increases.

コピー回避で比例しながらコピーによる不十分な性能を示していて、改良された例は説明に役立っています。 仕事[PDZ99]が、より高いサーバスループットを示している無コピーシステムを使用することで、より多くのクライアントにサービスを提供するIO-Lite。 TCP WAN接続のサーバへの効果をシミュレートすることによって本当の世界ウェブ状態をまねるように設計された実験では、3つのサーバの性能は比較されました。 1つのサーバがアパッチでした、そして、別のものはFlashと呼ばれる最適化されたサーバでした、そして、3番目がFlashサーバの実行しているIO-Liteであった、ゼロがある呼ばれたFlash-Liteはコピーします。 測定には、スループットが役立つことができた遅いバックグラウンドクライアントの数の関数として要求/秒にありました。 テーブルが示すように、特にクライアントの数が増加するようにFlash-Liteには、より良い効率があります。

              Apache              Flash         Flash-Lite
              ------              -----         ----------
   #Clients   Throughput reqs/s   Throughput    Throughput

アパッチフラッシュフラッシュ-Lite------ ----- ---------- #クライアントThroughput reqs/s Throughput Throughput

   0          520                 610           890
   16         390                 490           890
   32         360                 490           850
   64         360                 490           890
   128        310                 450           880
   256        310                 440           820

0 520 610 890 16 390 490 890 32 360 490 850 64 360 490 890 128 310 450 880 256 310 440 820

Romanow, et al.              Informational                      [Page 9]

RFC 4297             RDMA over IP Problem Statement        December 2005

Romanow、他 IP問題声明2005年12月の間の情報[9ページ]のRFC4297RDMA

   Traditional Web servers (which mostly send data and can keep most of
   their content in the file cache) are not the worst case for copy
   overhead.  Web proxies (which often receive as much data as they
   send) and complex Web servers based on System Area Networks or
   multi-tier systems will suffer more from copy overheads than in the
   example above.

伝統的なウェブサーバ(データをほとんど送って、ファイルキャッシュにおけるそれらの内容の大部分を保つことができる)はコピーオーバーヘッドのための最悪の場合ではありません。 ウェブプロキシ(しばしば送るのと同じくらい多くのデータを受け取る)とSystem Area Networksか多層のシステムに基づく複雑なウェブサーバは上記の例よりコピーオーバーヘッドに苦しむでしょう。

5.  Copy Avoidance Techniques

5. コピー回避のテクニック

   There have been extensive research investigation and industry
   experience with two main alternative approaches to eliminating data
   movement overhead, often along with improving other Operating System
   processing costs.  In one approach, hardware and/or software changes
   within a single host reduce processing costs.  In another approach,
   memory-to-memory networking [MAF+02], the exchange of explicit data
   placement information between hosts allows them to reduce processing
   costs.

大規模な研究調査と産業経験がデータ動きオーバーヘッドを取り除くことへの2つの主な代替的アプローチと共にありました、他のOperating System処理コストをしばしば向上させると共に。 1つのアプローチでは、独身のホストの中のハードウェア、そして/または、ソフトウェア変化は処理コストを削減します。 別のアプローチ、[MAF+02]をネットワークでつなぐメモリによって、彼らはホストの間の明白なデータプレースメント情報の交換で処理コストを削減できます。

   The single host approaches range from new hardware and software
   architectures [KSZ95, Wa97, DWB+93] to new or modified software
   systems [BS96, Ch96, TK95, DP93, PDZ99].  In the approach based on
   using a networking protocol to exchange information, the network
   adapter, under control of the application, places data directly into
   and out of application buffers, reducing the need for data movement.
   Commonly this approach is called RDMA, Remote Direct Memory Access.

ただ一つのホストアプローチは新しいハードウェアとソフトウェア・アーキテクチャ[KSZ95、Wa97、DWB+93]から新しいか変更されたソフトウェア・システム[BS96、Ch96、TK95、DP93、PDZ99]まで及びます。 情報交換するのにネットワーク・プロトコルを使用することに基づいたアプローチに、アプリケーションで制御されたネットワークアダプターはデータをバッファの中と、そして、直接アプリケーションバッファから置きます、データ運動の必要性を減少させて。 一般的に、このアプローチはRDMA、Remote Direct Memory Accessと呼ばれます。

   As discussed below, research and industry experience has shown that
   copy avoidance techniques within the receiver processing path alone
   have proven to be problematic.  The research special purpose host
   adapter systems had good performance and can be seen as precursors
   for the commercial RDMA-based adapters [KSZ95, DWB+93].  In software,
   many implementations have successfully achieved zero-copy transmit,
   but few have accomplished zero-copy receive.  And those that have
   done so make strict alignment and no-touch requirements on the
   application, greatly reducing the portability and usefulness of the
   implementation.

以下で議論するように、研究と産業経験は、受信機プロセシング・パスだけの中のコピー回避のテクニックが問題が多いと判明したのを示しました。 研究の専用ホストアダプターシステムを、望ましい市場成果を持って、市販のRDMAベースのアダプターのための先駆と考えることができます[KSZ95、DWB+93]。 ソフトウェアでは、首尾よく達成された無コピーは多くの実装で伝わりますが、わずかでしか、優れた無コピーは受信されません。 そして、厳しい整列をしますが、そうしたものはアプリケーションのときにどんな接触も要件にしません、実装の移植性と有用性を大いに減少させて。

   In contrast, experience has proven satisfactory with memory-to-memory
   systems that permit RDMA; performance has been good and there have
   not been system or networking difficulties.  RDMA is a single
   solution.  Once implemented, it can be used with any OS and machine
   architecture, and it does not need to be revised when either of these
   are changed.

対照的に、経験はRDMAを可能にするメモリからメモリシステムで満足できると判明しました。 性能は良いです、そして、システムかネットワーク困難がありませんでした。 RDMAはただ一つのソリューションです。 一度実装されます、いずれと共にも使用されて、これらのどちらかであるときに改訂されるべき必要性ではなく、アーキテクチャ、およびそれがそうするOSとマシンを変えるということであるかもしれません。

   In early work, one goal of the software approaches was to show that
   TCP could go faster with appropriate OS support [CJRS89, CFF+94].
   While this goal was achieved, further investigation and experience
   showed that, though possible to craft software solutions, specific

早めの仕事では、ソフトウェアアプローチの1つの目標はTCPが、より速く、適切なOSサポート[CJRS89、CFF+94]を伴うことができるのを示すことでした。 この目標は達成されましたが、工芸品のソフトウェアソリューションに可能であって、特定ですが、さらなる調査と経験はそれを示しました。

Romanow, et al.              Informational                     [Page 10]

RFC 4297             RDMA over IP Problem Statement        December 2005

Romanow、他 IP問題声明2005年12月の間の情報[10ページ]のRFC4297RDMA

   system optimizations have been complex, fragile, extremely
   interdependent with other system parameters in complex ways, and
   often of only marginal improvement [CFF+94, CGY01, Ch96, DAPP93,
   KSZ95, PDZ99].  The network I/O system interacts with other aspects
   of the Operating System such as machine architecture and file I/O,
   and disk I/O [Br99, Ch96, DP93].

システム最適化は複雑です、こわれやすいです、複雑な道と、しばしばわずかな改善[CFF+94、CGY01、Ch96、DAPP93、KSZ95、PDZ99]だけに関する他のシステム・パラメータで非常に互いに依存しています。 ネットワーク入出力システムはOperating Systemのマシンアーキテクチャや、ファイル入出力や、ディスク入出力[Br99、Ch96、DP93]などの他の局面と対話します。

   For example, the Solaris Zero-Copy TCP work [Ch96], which relies on
   page remapping, shows that the results are highly interdependent with
   other systems, such as the file system, and that the particular
   optimizations are specific for particular architectures, meaning that
   for each variation in architecture, optimizations must be re-crafted
   [Ch96].

例えば、Solaris Zero-コピーTCP仕事[Ch96](ページ再写像を当てにする)は結果がファイルシステムなどの他のシステムで非常に互いに依存していて、特定のアーキテクチャに、特定の最適化が特定であることを示します、アーキテクチャの各変化において、最適化を再作らなければならないことを[Ch96]意味して。

   With RDMA, application I/O buffers are mapped directly, and the
   authorized peer may access it without incurring additional processing
   overhead.  When RDMA is implemented in hardware, arbitrary data
   movement can be performed without involving the host CPU at all.

RDMAと共に、アプリケーション入出力バッファは直接写像されます、そして、追加処理オーバヘッドを被らないで、認可された同輩はそれにアクセスするかもしれません。 RDMAがハードウェアで実装されるとき、全くホストCPUにかかわらないで、任意のデータ運動を実行できます。

   A number of research projects and industry products have been based
   on the memory-to-memory approach to copy avoidance.  These include
   U-Net [EBBV95], SHRIMP [BLA+94], Hamlyn [BJM+96], Infiniband [IB],
   Winsock Direct [Pi01].  Several memory-to-memory systems have been
   widely used and have generally been found to be robust, to have good
   performance, and to be relatively simple to implement.  These include
   VI [VI], Myrinet [BCF+95], Quadrics [QUAD], Compaq/Tandem Servernet
   [SRVNET].  Networks based on these memory-to-memory architectures
   have been used widely in scientific applications and in data centers
   for block storage, file system access, and transaction processing.

多くの研究計画と工業製品が、回避をコピーするためにメモリからメモリへのアプローチに基づきました。 これらはU-ネット[EBBV95]、SHRIMP[BLA+94]、Hamlyn[BJM+96]、Infiniband[IB]、ウィンソックDirect[Pi01]を含んでいます。 数個のメモリからメモリシステムが、広く使用されて、一般に、強健であり、望ましい市場成果を持って、実装するのが比較的簡単であることがわかりました。 これらはVI[VI]、Myrinet[BCF+95]、Quadrics[QUAD]、コンパック/2人乗り自転車Servernet[SRVNET]を含んでいます。 メモリからメモリへのこれらのアーキテクチャに基づくネットワークはブロックストレージ、ファイルシステムアクセス、およびトランザクション処理に科学的な応用とデータセンターで広く使用されました。

   By exporting direct memory access "across the wire", applications may
   direct the network stack to manage all data directly from application
   buffers.  A large and growing class that takes advantage of such
   capabilities of applications has already emerged.  It includes all
   the major databases, as well as network protocols such as Sockets
   Direct [SDP].

ダイレクトメモリアクセスが「ワイヤ」であるとエクスポートすることによって、アプリケーションは、直接アプリケーションバッファからのすべてのデータを管理するようネットワークスタックに指示するかもしれません。 アプリケーションのそのような能力を利用する大きくて増加しているクラスは既に現れました。 それはSockets Direct[SDP]などのネットワーク・プロトコルと同様にすべての主要なデータベースを含んでいます。

5.1.  A Conceptual Framework: DDP and RDMA

5.1. 概念の構成: DDPとRDMA

   An RDMA solution can be usefully viewed as being comprised of two
   distinct components: "direct data placement (DDP)" and "remote direct
   memory access (RDMA) semantics".  They are distinct in purpose and
   also in practice -- they may be implemented as separate protocols.

2つの異なったコンポーネントから成ると有効にRDMAソリューションを見なすことができます: 「ダイレクトデータプレースメント(DDP)」と「リモートダイレクトメモリアクセス(RDMA)意味論。」 それらは目的と習慣においても異なっています--それらは別々のプロトコルとして実装されるかもしれません。

   The more fundamental of the two is the direct data placement
   facility.  This is the means by which memory is exposed to the remote
   peer in an appropriate fashion, and the means by which the peer may
   access it, for instance, reading and writing.

2つのものについて、より基本的なことはダイレクトデータプレースメント施設です。 これは、メモリが適切なファッションでリモート同輩に暴露される手段と、同輩がそれ、例えば読み書きにアクセスするかもしれない手段です。

Romanow, et al.              Informational                     [Page 11]

RFC 4297             RDMA over IP Problem Statement        December 2005

Romanow、他 IP問題声明2005年12月の間の情報[11ページ]のRFC4297RDMA

   The RDMA control functions are semantically layered atop direct data
   placement.  Included are operations that provide "control" features,
   such as connection and termination, and the ordering of operations
   and signaling their completions.  A "send" facility is provided.

RDMAコントロール機能はダイレクトデータプレースメントの上で意味的に層にされます。 含まれているのは、接続や終了などの「コントロール」の特徴、および操作とシグナリングの注文に彼らの落成を提供する操作です。 「発信してください」という施設を提供します。

   While the functions (and potentially protocols) are distinct,
   historically both aspects taken together have been referred to as
   "RDMA".  The facilities of direct data placement are useful in and of
   themselves, and may be employed by other upper layer protocols to
   facilitate data transfer.  Therefore, it is often useful to refer to
   DDP as the data placement functionality and RDMA as the control
   aspect.

機能(そして、潜在的にプロトコル)が異なっている間、歴史的に、一緒に取られた両方の局面は"RDMA"と呼ばれています。 ダイレクトデータプレースメントの施設は自分たちと自分たちで役に立って、他の上側の層のプロトコルによって使われて、データ転送を容易にするかもしれません。 したがって、コントロール局面としてデータプレースメントの機能性とRDMAとDDPを呼ぶのはしばしば役に立ちます。

   [BT05] develops an architecture for DDP and RDMA atop the Internet
   Protocol Suite, and is a companion document to this problem
   statement.

[BT05]は、DDPとRDMAのためにインターネットプロトコルSuiteの上でアーキテクチャを開発して、この問題声明への仲間ドキュメントです。

6.  Conclusions

6. 結論

   This Problem Statement concludes that an IP-based, general solution
   for reducing processing overhead in end-hosts is desirable.

このProblem Statementは、終わりホストで処理のオーバーヘッドを減らすためのIPベース的、そして、一般的なソリューションが望ましいと結論を下します。

   It has shown that high overhead of the processing of network data
   leads to end-host bottlenecks.  These bottlenecks are in large part
   attributable to the copying of data.  The bus bandwidth of machines
   has historically been limited, and the bandwidth of high-speed
   interconnects taxes it heavily.

それは、ネットワークデータの処理の高いオーバーヘッドが終わりホストボトルネックに通じるのを示しました。 これらのボトルネックは主にデータのコピーに起因しています。 マシンのバス帯域幅は歴史的に制限されました、そして、高速内部連絡の帯域幅は大いにそれに税をかけます。

   An architectural solution to alleviate these bottlenecks best
   satisfies the issue.  Further, the high speed of today's
   interconnects and the deployment of these hosts on Internet
   Protocol-based networks leads to the desirability of layering such a
   solution on the Internet Protocol Suite.  The architecture described
   in [BT05] is such a proposal.

これらのボトルネックを最もよく軽減する建築溶液は問題を満たします。 さらに、今日の内部連絡の高速とインターネットのプロトコルを拠点とするネットワークにおけるこれらのホストの展開はインターネットプロトコルSuiteでそのようなソリューションを層にする願わしさにつながります。 [BT05]で説明されたアーキテクチャはそのような提案です。

7.  Security Considerations

7. セキュリティ問題

   Solutions to the problem of reducing copying overhead in high
   bandwidth transfers may introduce new security concerns.  Any
   proposed solution must be analyzed for security vulnerabilities and
   any such vulnerabilities addressed.  Potential security weaknesses --
   due to resource issues that might lead to denial-of-service attacks,
   overwrites and other concurrent operations, the ordering of
   completions as required by the RDMA protocol, the granularity of
   transfer, and any other identified vulnerabilities -- need to be
   examined, described, and an adequate resolution to them found.

高帯域転送でオーバーヘッドをコピーしながら減少するという問題の解決は新しい安全上の配慮を導入するかもしれません。 脆弱性とどんなそのような脆弱性も扱ったセキュリティのためにどんな提案されたソリューションも分析しなければなりません。 必要に応じてRDMAでサービス不能攻撃と重ね書きと他の並行操作、落成の注文につながるかもしれないリソース問題による潜在的セキュリティ弱点は議定書を作ります、転送の粒状、そして、いかなる他のも脆弱性を特定しました--調べられて、説明されるべき必要性、およびそれらにおいて見つけられた適切な解決。

Romanow, et al.              Informational                     [Page 12]

RFC 4297             RDMA over IP Problem Statement        December 2005

Romanow、他 IP問題声明2005年12月の間の情報[12ページ]のRFC4297RDMA

   Layered atop Internet transport protocols, the RDMA protocols will
   gain leverage from and must permit integration with Internet security
   standards, such as IPsec and TLS [IPSEC, TLS].  However, there may be
   implementation ramifications for certain security approaches with
   respect to RDMA, due to its copy avoidance.

インターネットの上でトランスポート・プロトコル、プロトコルがてこの作用を獲得するRDMAを層にして、IPsecやTLSなどのインターネット機密保護基準[IPSEC、TLS]で統合を可能にしなければなりません。 しかしながら、RDMAに関して、あるセキュリティアプローチのための実装分岐がコピー回避のためにあるかもしれません。

   IPsec, operating to secure the connection on a packet-by-packet
   basis, seems to be a natural fit to securing RDMA placement, which
   operates in conjunction with transport.  Because RDMA enables an
   implementation to avoid buffering, it is preferable to perform all
   applicable security protection prior to processing of each segment by
   the transport and RDMA layers.  Such a layering enables the most
   efficient secure RDMA implementation.

パケットごとのベースで接続を保証するために作動して、IPsecは、RDMAが輸送に関連して作動するプレースメントであると機密保護することへの自然な発作であるように思えます。 RDMAが、実装が、バッファリングするのを避けるのを可能にするので、それぞれのセグメントの処理の前に輸送とRDMA層のそばですべての適切な機密保持を実行するのは望ましいです。 そのようなレイヤリングは最も効率的な安全なRDMA実装を可能にします。

   The TLS record protocol, on the other hand, is layered on top of
   reliable transports and cannot provide such security assurance until
   an entire record is available, which may require the buffering and/or
   assembly of several distinct messages prior to TLS processing.  This
   defers RDMA processing and introduces overheads that RDMA is designed
   to avoid.  Therefore, TLS is viewed as potentially a less natural fit
   for protecting the RDMA protocols.

TLSの記録的なプロトコルは、他方では、信頼できる輸送の上で層にされて、全体の記録が利用可能になるまで、そのような安全保証を提供できません、どれがバッファリングを必要とするかもしれないか、そして、そして/または、TLSの前のいくつかの異なったメッセージのアセンブリが処理されて。 これは、RDMA処理を延期して、RDMAが避けるように設計されているオーバーヘッドを導入します。 したがって、より少ない生まれつきの名手がRDMAプロトコルを保護するために潜在的に合ったので、TLSは見られます。

   It is necessary to guarantee properties such as confidentiality,
   integrity, and authentication on an RDMA communications channel.
   However, these properties cannot defend against all attacks from
   properly authenticated peers, which might be malicious, compromised,
   or buggy.  Therefore, the RDMA design must address protection against
   such attacks.  For example, an RDMA peer should not be able to read
   or write memory regions without prior consent.

RDMAコミュニケーションチャンネルの上に秘密性や、保全や、認証などの特性を保証するのが必要です。 しかしながら、これらの特性は適切に認証された同輩からの攻撃(悪意があるかもしれない)が感染したすべて、またはバギーに対して防御されることができません。 したがって、RDMAデザインはそのような攻撃に対する保護を扱わなければなりません。 例えば、RDMA同輩は、先の同意なしでメモリ領域を読むべきではありませんし、書くことができないべきです。

   Further, it must not be possible to evade memory consistency checks
   at the recipient.  The RDMA design must allow the recipient to rely
   on its consistent memory contents by explicitly controlling peer
   access to memory regions at appropriate times.

さらに、受取人でメモリ一貫性チェックを回避するのは可能であるはずがありません。 RDMAデザインで、受取人は、適切な時期で明らかにメモリ領域への同輩アクセスを制御することによって、一貫した記憶内容を当てにすることができなければなりません。

   Peer connections that do not pass authentication and authorization
   checks by upper layers must not be permitted to begin processing in
   RDMA mode with an inappropriate endpoint.  Once associated, peer
   accesses to memory regions must be authenticated and made subject to
   authorization checks in the context of the association and connection
   on which they are to be performed, prior to any transfer operation or
   data being accessed.

上側の層で認証と許可検査を通過しない同輩接続が不適当な終点でRDMAモードで処理し始めるのが許容されてはいけません。 いったん関連づけると、それらが実行されることになっている協会と接続の文脈における許可検査を条件としてメモリ領域への同輩アクセスを認証して、しなければなりません、アクセスされるどんな転送操作やデータの前にも。

   The RDMA protocols must ensure that these region protections be under
   strict application control.  Remote access to local memory by a
   network peer is particularly important in the Internet context, where
   such access can be exported globally.

RDMAプロトコルは、これらの領域保護が厳しいアプリケーション制御装置の下でそうであることを確実にしなければなりません。 ネットワーク同輩によるローカルの記憶への遠隔アクセスはインターネット文脈で特に重要です。そこでは、そのようなアクセスをグローバルにエクスポートすることができます。

Romanow, et al.              Informational                     [Page 13]

RFC 4297             RDMA over IP Problem Statement        December 2005

Romanow、他 IP問題声明2005年12月の間の情報[13ページ]のRFC4297RDMA

8.  Terminology

8. 用語

   This section contains general terminology definitions for this
   document and for Remote Direct Memory Access in general.

このセクションはこのドキュメントと一般に、Remote Direct Memory Accessのための一般的な用語定義を含みます。

   Remote Direct Memory Access (RDMA)
        A method of accessing memory on a remote system in which the
        local system specifies the location of the data to be
        transferred.

ローカルシステムがデータの位置を指定するリモートシステムの上に関するメモリにアクセスする移されるべきリモートDirect Memory Access(RDMA)Aメソッド。

   RDMA Protocol
        A protocol that supports RDMA Operations to transfer data
        between systems.

システムの間にデータを移すためにRDMA OperationsをサポートするRDMAプロトコルAプロトコル。

   Fabric
        The collection of links, switches, and routers that connect a
        set of systems.

骨組み、1セットのシステムを接続するリンク集、スイッチ、およびルータ。

   Storage Area Network (SAN)
        A network where disks, tapes, and other storage devices are made
        available to one or more end-systems via a fabric.

ストレージ・エリア・ネットワーク(SAN)Aは骨組みで1がどこでディスク、テープ、および他の記憶装置を入手するか、そして、より多くのエンドシステムをネットワークでつなぎます。

   System Area Network
        A network where clustered systems share services, such as
        storage and interprocess communication, via a fabric.

システムArea Network Aは骨組みでクラスタリングしているシステムがどこでストレージなどのサービスを共有するか、そして、プロセス間通信をネットワークでつなぎます。

   Fibre Channel (FC)
        An ANSI standard link layer with associated protocols, typically
        used to implement Storage Area Networks. [FIBRE]

ANSI規格がリンクする繊維Channel(FC)はStorage Area Networksを実装するのに通常使用される関連プロトコルで層にします。 [繊維]

   Virtual Interface Architecture (VI, VIA)
        An RDMA interface definition developed by an industry group and
        implemented with a variety of differing wire protocols. [VI]

RDMAインターフェース定義が同業種グループで開発して、さまざまな異なったワイヤプロトコルで実装したVIアーキテクチャ(VI、VIA)。 [VI]

   Infiniband (IB)
        An RDMA interface, protocol suite and link layer specification
        defined by an industry trade association. [IB]

RDMAが連結するInfiniband(IB)、プロトコル群、およびリンクは産業産業団体によって定義された仕様を層にします。 [イブ]

9.  Acknowledgements

9. 承認

   Jeff Chase generously provided many useful insights and information.
   Thanks to Jim Pinkerton for many helpful discussions.

ジェフ・チェイスは気前よく多くの役に立つ洞察と情報を提供しました。 多くの役立つ議論をジム・ピンカートンをありがとうございます。

Romanow, et al.              Informational                     [Page 14]

RFC 4297             RDMA over IP Problem Statement        December 2005

Romanow、他 IP問題声明2005年12月の間の情報[14ページ]のRFC4297RDMA

10.  Informative References

10. 有益な参照

   [ATM]      The ATM Forum, "Asynchronous Transfer Mode Physical Layer
              Specification" af-phy-0015.000, etc.  available from
              http://www.atmforum.com/standards/approved.html.

[ATM] ATM Forum、 http://www.atmforum.com/standards/approved.html から利用可能な「非同期通信モードの物理的な層の仕様」af-phy-0015.000など。

   [BCF+95]   N. J. Boden, D. Cohen, R. E. Felderman, A. E. Kulawik, C.
              L. Seitz, J. N. Seizovic, and W. Su. "Myrinet - A
              gigabit-per-second local-area network", IEEE Micro,
              February 1995.

[BCF+95] N.J.ブーデン、D.コーエン、R.E.Felderman、A.E.Kulawik、C.L.サイツ、J.N.Seizovic、およびW.Su。 「Myrinet--、1秒あたりのギガビットローカル・エリア・ネットワーク、」、IEEE Micro、2月1995日

   [BJM+96]   G. Buzzard, D. Jacobson, M. Mackey, S. Marovich, J.
              Wilkes, "An implementation of the Hamlyn send-managed
              interface architecture", in Proceedings of the Second
              Symposium on Operating Systems Design and Implementation,
              USENIX Assoc., October 1996.

G.Buzzard、D.ジェーコブソン、M.マッケイ、S.Marovich、[BJM+96]J.ウィルクス、「Hamlynの実装、発信、-、管理、」 Operating Systems Designの上のSecond SymposiumのProceedingsとImplementation(USENIX Assoc)の1996年10月にアーキテクチャを連結してください。

   [BLA+94]   M. A. Blumrich, K. Li, R. Alpert, C. Dubnicki, E. W.
              Felten, "A virtual memory mapped network interface for the
              SHRIMP multicomputer", in Proceedings of the 21st Annual
              Symposium on Computer Architecture, April 1994, pp. 142-
              153.

[BLA+94] M.A.Blumrich、K.李、R.アルパート、C.Dubnicki、E.W.Felten、「仮想記憶はSHRIMP多重コンピュータのためにネットワーク・インターフェースを写像しました」、コンピュータArchitectureの上の第21Annual SymposiumのProceedingsで、1994年4月、ページ 142- 153.

   [Br99]     J. C. Brustoloni, "Interoperation of copy avoidance in
              network and file I/O", Proceedings of IEEE Infocom, 1999,
              pp. 534-542.

[Br99]J.C.Brustoloni、「ネットワークにおけるコピー回避とファイル入出力のInteroperation」、IEEE Infocom、1999、ページのProceedings 534-542.

   [BS96]     J. C. Brustoloni, P. Steenkiste, "Effects of buffering
              semantics on I/O performance", Proceedings OSDI'96,
              USENIX, Seattle, WA October 1996, pp. 277-291.

[BS96] J.C.Brustoloni、P.Steenkiste、「意味論をバッファリングするという入出力性能への効果」、Proceedings OSDI96年、USENIX、シアトルワシントン1996年10月、ページ 277-291.

   [BT05]     Bailey, S. and T. Talpey, "The Architecture of Direct Data
              Placement (DDP) And Remote Direct Memory Access (RDMA) On
              Internet Protocols", RFC 4296, December 2005.

[BT05] べイリーとS.とT.Talpey、「インターネットプロトコルのダイレクトデータプレースメント(DDP)とリモートダイレクトメモリアクセス(RDMA)のアーキテクチャ」、RFC4296、2005年12月。

   [CFF+94]   C-H Chang, D. Flower, J. Forecast, H. Gray, B. Hawe, A.
              Nadkarni, K. K. Ramakrishnan, U. Shikarpur, K. Wilde,
              "High-performance TCP/IP and UDP/IP networking in DEC
              OSF/1 for Alpha AXP",  Proceedings of the 3rd IEEE
              Symposium on High Performance Distributed Computing,
              August 1994, pp. 36-42.

[CFF+94] C-Hチャンと、D.Flowerと、J.Forecastと、H.グレーと、B.Haweと、A.Nadkarniと、K.K.Ramakrishnan、U.シカルプールと、K.ワイルドと、「高性能TCP/IPと12月にアルファーAXPのためにOSF/1をネットワークでつなぐUDP/IP」、HighパフォーマンスDistributed Computing、1994年8月、ページの第3IEEE SymposiumのProceedings 36-42.

   [CGY01]    J. S. Chase, A. J. Gallatin, and K. G. Yocum, "End system
              optimizations for high-speed TCP", IEEE Communications
              Magazine, Volume: 39, Issue: 4 , April 2001, pp 68-74.
              http://www.cs.duke.edu/ari/publications/end-
              system.{ps,pdf}.

[CGY01]J.S.チェイス、A.J.ガラティンとK.G.Yocum、「高速TCPのための終わりのシステム最適化」IEEE Communications Magazine、Volume: 39 問題: 4 pp68-74 http://www.cs.duke.edu/ari/publications/end- システム2001年4月、ps、pdf。

Romanow, et al.              Informational                     [Page 15]

RFC 4297             RDMA over IP Problem Statement        December 2005

Romanow、他 IP問題声明2005年12月の間の情報[15ページ]のRFC4297RDMA

   [Ch96]     H.K. Chu, "Zero-copy TCP in Solaris", Proc. of the USENIX
              1996 Annual Technical Conference, San Diego, CA, January
              1996.

[Ch96]H.K.チュウ、「Solarisの無コピーTCP」Proc1996年のUSENIXの年に一度の技術的なコンファレンス、サンディエゴ(カリフォルニア)1996年1月について。

   [Ch02]     Jeffrey Chase, Personal communication.

[Ch02] ジェフリー・チェイス、パーソナルコミュニケーション。

   [CJRS89]   D. D. Clark, V. Jacobson, J. Romkey, H. Salwen, "An
              analysis of TCP processing overhead", IEEE Communications
              Magazine, volume:  27, Issue: 6, June 1989, pp 23-29.

[CJRS89] D.D.クラーク、V.ジェーコブソン、J.Romkey、H.Salwen、「TCP処理オーバヘッドの分析」、IEEE Communications Magazine、ボリューム: 27 問題: 6 1989年6月、pp23-29。

   [CT90]     D. D. Clark, D. Tennenhouse, "Architectural considerations
              for a new generation of protocols", Proceedings of the ACM
              SIGCOMM Conference, 1990.

[CT90] D.D.クラーク、D.Tennenhouse、「プロトコルの新しい世代建築問題」、ACM SIGCOMMコンファレンス、1990年のProceedings。

   [DAPP93]   P. Druschel, M. B. Abbott, M. A. Pagels, L. L. Peterson,
              "Network subsystem design", IEEE Network, July 1993, pp.
              8-17.

[DAPP93]P.Druschel、M.B.アボット、M.A.ペイゲルス、L.L.ピーターソン、「ネットワークサブシステムデザイン」、IEEE Network、1993年7月、ページ 8-17.

   [DP93]     P. Druschel, L. L. Peterson, "Fbufs: a high-bandwidth
              cross-domain transfer facility", Proceedings of the 14th
              ACM Symposium of Operating Systems Principles, December
              1993.

[DP93]P.Druschel、L.L.ピーターソン、「Fbufs:」 「高帯域交差しているドメイン中継設備」、Operating Systemsプリンシプルズ、1993年12月の第14ACM SymposiumのProceedings。

   [DWB+93]   C. Dalton, G. Watson, D. Banks, C. Calamvokis, A. Edwards,
              J. Lumley, "Afterburner: architectural support for high-
              performance protocols", Technical Report, HP Laboratories
              Bristol, HPL-93-46, July 1993.

C.ドルトン、G.ワトソン、D.銀行、C.Calamvokis、A.エドワーズ、[DWB+93]J.ラムリー、「アフターバーナー:」 「高い性能プロトコルの建築サポート」、Technical Report、ヒューレット・パッカード研究所ブリストルHPL-93-46、1993年7月。

   [EBBV95]   T. von Eicken, A. Basu, V. Buch, and W. Vogels, "U-Net: A
              user-level network interface for parallel and distributed
              computing", Proc. of the 15th ACM Symposium on Operating
              Systems Principles, Copper Mountain, Colorado, December
              3-6, 1995.

[EBBV95]T.フォンEicken(A.Basu、V.ブーフ、およびW.Vogels)は「以下をUで網状になります」。 「ユーザレベルネットワークは平行と分散コンピューティングのために連結します」、Proc。. Operating Systemsプリンシプルズ、カッパーマウンテン(コロラド)、1995年12月3日〜6日の第15ACM Symposiumについて。

   [FDDI]     International Standards Organization, "Fibre Distributed
              Data Interface", ISO/IEC 9314, committee drafts available
              from http://www.iso.org.

[FDDI]国際Standards Organization、「繊維分散データは連結する」ISO/IEC9314、 http://www.iso.org から利用可能な委員会のドラフト。

   [FGM+99]   Fielding,  R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[FGM+99] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」

   [FIBRE]    ANSI Technical Committee T10, "Fibre Channel Protocol
              (FCP)" (and as revised and updated), ANSI X3.269:1996
              [R2001], committee draft available from
              http://www.t10.org/drafts.htm#FibreChannel

http://www.t10.org/drafts.htm#FibreChannel から利用可能な[FIBRE]ANSI Technical Committee T10、「繊維チャンネルプロトコル(FCP)」(改訂して、アップデートするように)、ANSI X3.269:1996[R2001]委員会のドラフト

Romanow, et al.              Informational                     [Page 16]

RFC 4297             RDMA over IP Problem Statement        December 2005

Romanow、他 IP問題声明2005年12月の間の情報[16ページ]のRFC4297RDMA

   [HP97]     J. L. Hennessy, D. A. Patterson, Computer Organization and
              Design, 2nd Edition, San Francisco: Morgan Kaufmann
              Publishers, 1997.

[HP97]J.L.ヘネシーとD.A.パターソンとコンピュータ組織とデザイン、第2版、サンフランシスコ: モーガンコフマン出版社、1997。

   [IB]       InfiniBand Trade Association, "InfiniBand Architecture
              Specification, Volumes 1 and 2", Release 1.1, November
              2002, available from http://www.infinibandta.org/specs.

[IB]インフィニバンドTrade Association、「インフィニバンドアーキテクチャ仕様(第1巻と2インチ)は、1.1、 http://www.infinibandta.org/specs から空いている2002年11月をリリースします」。

   [IPSEC]    Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

[IPSEC] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。

   [KP96]     J. Kay, J. Pasquale, "Profiling and reducing processing
              overheads in TCP/IP", IEEE/ACM Transactions on Networking,
              Vol 4, No. 6, pp.817-828, December 1996.

[KP96] J.ケイ、J.パスクアーレ、「TCP/IPで処理オーバヘッドを輪郭を描いて、下げる」Networkingの上のIEEE/ACM Transactions、Vol4、No.6、pp.817-828(1996年12月)。

   [KSZ95]    K. Kleinpaste, P. Steenkiste, B. Zill, "Software support
              for outboard buffering and checksumming", SIGCOMM'95.

[KSZ95] K.Kleinpaste、P.Steenkiste、B.Zill、「船外のバッファリングとchecksummingのソフトウェアサポート」、SIGCOMM95年。

   [Ma02]     K. Magoutis, "Design and Implementation of a Direct Access
              File System (DAFS) Kernel Server for FreeBSD", in
              Proceedings of USENIX BSDCon 2002 Conference, San
              Francisco, CA, February 11-14, 2002.

[Ma02]K.Magoutis、「直接アクセスのデザインと実装は無料OSの一つのためにシステム(ダフ)カーネルサーバをファイルします」、2002年のUSENIX BSDConコンファレンスの議事で、サンフランシスコ(カリフォルニア)2002年2月11日〜14日。

   [MAF+02]   K. Magoutis, S. Addetia, A. Fedorova, M.  I. Seltzer, J.
              S. Chase, D. Gallatin, R. Kisley, R. Wickremesinghe, E.
              Gabber, "Structure and Performance of the Direct Access
              File System (DAFS)", in Proceedings of the 2002 USENIX
              Annual Technical Conference, Monterey, CA, June 9-14,
              2002.

[MAF+02] K.Magoutis、S.Addetia、A.Fedorova、M.I.セルツァー、J.S.チェイス、D.ガラティン、R.Kisley、R.ウィクラマシンハ、E.時事解説者、「直接アクセスの構造とパフォーマンスはシステム(ダフ)をファイルします」、2002年のUSENIXの年に一度の技術的なコンファレンスの議事で、モントレー(カリフォルニア)2002年6月9日〜14日。

   [Mc95]     J. D. McCalpin, "A Survey of memory bandwidth and machine
              balance in current high performance computers", IEEE TCCA
              Newsletter, December 1995.

[Mc95]J.D.McCalpin、「現在の高性能コンピュータのメモリ帯域幅とマシンバランスのSurvey」、IEEE TCCAニュースレター(1995年12月)。

   [PAC+97]   D. Patterson, T. Anderson, N. Cardwell, R. Fromm, K.
              Keeton, C. Kozyrakis, R. Thomas, K. Yelick , "A case for
              intelligient RAM: IRAM", IEEE Micro, April 1997.

[PAC+97] D.パターソン、T.アンダーソン、N.カードウェル、R.フロム、K.キートン、C.Kozyrakis、R.トーマス、K.Yelick、「Aはintelligient RAMのために以下をケースに入れます」。 "IRAM"、IEEEミクロ、1997年4月。

   [PDZ99]    V. S. Pai, P. Druschel, W. Zwaenepoel, "IO-Lite: a unified
              I/O buffering and caching system", Proc. of the 3rd
              Symposium on Operating Systems Design and Implementation,
              New Orleans, LA, February 1999.

[PDZ99]V.S.パイ、P.Druschel、W.Zwaenepoel、「キン青石:」 「aはシステムをバッファリングして、キャッシュする入出力を統一しました」、Proc。. Operating Systems Designの上の第3SymposiumとImplementation、ニューオリンズ(LA)1999年2月について。

   [Pi01]     J. Pinkerton, "Winsock Direct: The Value of System Area
              Networks", May 2001, available from
              http://www.microsoft.com/windows2000/techinfo/
              howitworks/communications/winsock.asp.

[Pi01]J.ピンカートン、「ウィンソックは以下を指示します」。 http://www.microsoft.com/windows2000/techinfo/ howitworks/コミュニケーション/winsock.aspからの2001年5月に利用可能な「System Area NetworksのValue。」

Romanow, et al.              Informational                     [Page 17]

RFC 4297             RDMA over IP Problem Statement        December 2005

Romanow、他 IP問題声明2005年12月の間の情報[17ページ]のRFC4297RDMA

   [Po81]     Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.

[Po81] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。

   [QUAD]     Quadrics Ltd., Quadrics QSNet product information,
              available from
              http://www.quadrics.com/website/pages/02qsn.html.

[QUAD]二次関数株式会社、 http://www.quadrics.com/website/pages/02qsn.html から利用可能なQuadrics QSNet製品情報。

   [SDP]      InfiniBand Trade Association, "Sockets Direct Protocol
              v1.0", Annex A of InfiniBand Architecture Specification
              Volume 1, Release 1.1, November 2002, available from
              http://www.infinibandta.org/specs.

[SDP]インフィニバンドTrade Association、「ソケットDirectプロトコルv1.0"、インフィニバンドArchitecture Specification Volume1、2002年11月に http://www.infinibandta.org/specs から利用可能なRelease1.1のAnnex A。」

   [SRVNET]   R. Horst, "TNet: A reliable system area network", IEEE
              Micro, pp. 37-45, February 1995.

[SRVNET]R.ホルスト、「TNet:」 「信頼できるシステム領域ネットワーク」、IEEE Micro、ページ 37-45と、1995年2月。

   [STREAM]   J. D. McAlpin, The STREAM Benchmark Reference Information,
              http://www.cs.virginia.edu/stream/.

[ストリーム]J.D.McAlpin、ストリームベンチマーク参考情報、 http://www.cs.virginia.edu/stream/ 。

   [TK95]     M. N. Thadani, Y. A. Khalidi, "An efficient zero-copy I/O
              framework for UNIX", Technical Report, SMLI TR-95-39, May
              1995.

[TK95]M.N.Thadani、Y.A.ハリディ、「UNIXに、効率的な無コピー入出力フレームワーク」、Technical Report、SMLI TR-95-39、1995年5月。

   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

[TLS] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。

   [VI]       D. Cameron and G. Regnier, "The Virtual Interface
              Architecture", ISBN 0971288704, Intel Press, April 2002,
              more info at http://www.intel.com/intelpress/via/.

[VI] D.キャメロンとG.レニエ、「VIアーキテクチャ」、ISBN0971288704、インテルPress、2002年4月、 http://www.intel.com/intelpress/via/ の詳しい情報。

   [Wa97]     J. R. Walsh, "DART: Fast application-level networking via
              data-copy avoidance", IEEE Network, July/August 1997, pp.
              28-38.

[Wa97]J.R.ウォルシュ、「投げてください」 「データコピー回避を通した速いアプリケーションレベルネットワーク」、IEEE Network、1997年7月/8月、ページ 28-38.

Romanow, et al.              Informational                     [Page 18]

RFC 4297             RDMA over IP Problem Statement        December 2005

Romanow、他 IP問題声明2005年12月の間の情報[18ページ]のRFC4297RDMA

Authors' Addresses

作者のアドレス

   Stephen Bailey
   Sandburst Corporation
   600 Federal Street
   Andover, MA  01810 USA

スティーブンべイリーSandburst社600の連邦政府の通りMA01810アンドーバー(米国)

   Phone: +1 978 689 1614
   EMail: steph@sandburst.com

以下に電話をしてください。 +1 1614年の978 689メール: steph@sandburst.com

   Jeffrey C. Mogul
   HP Labs
   Hewlett-Packard Company
   1501 Page Mill Road, MS 1117
   Palo Alto, CA  94304 USA

ヒューレット・パッカード会社1501ページ工場道路、1117パロアルト、ジェフリーC.要人hp研究室MSカリフォルニア94304米国

   Phone: +1 650 857 2206 (EMail preferred)
   EMail: JeffMogul@acm.org

以下に電話をしてください。 +1 650 857 2206(好まれたEMail)EMail: JeffMogul@acm.org

   Allyn Romanow
   Cisco Systems, Inc.
   170 W. Tasman Drive
   San Jose, CA  95134 USA

アリンRomanowシスコシステムズInc.170W.タスマン・Driveカリフォルニア95134サンノゼ(米国)

   Phone: +1 408 525 8836
   EMail: allyn@cisco.com

以下に電話をしてください。 +1 8836年の408 525メール: allyn@cisco.com

   Tom Talpey
   Network Appliance
   1601 Trapelo Road
   Waltham, MA  02451 USA

トムTalpeyネットアプライアンス1601Trapelo Road MA02451ウォルサム(米国)

   Phone: +1 781 768 5329
   EMail: thomas.talpey@netapp.com

以下に電話をしてください。 +1 5329年の781 768メール: thomas.talpey@netapp.com

Romanow, et al.              Informational                     [Page 19]

RFC 4297             RDMA over IP Problem Statement        December 2005

Romanow、他 IP問題声明2005年12月の間の情報[19ページ]のRFC4297RDMA

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

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

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

Romanow, et al.              Informational                     [Page 20]

Romanow、他 情報[20ページ]

一覧

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

スポンサーリンク

Math.asin

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

上に戻る