RFC 5532 - Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement 日本語訳

URL : https://tools.ietf.org/html/rfc5532
タイトル : RFC 5532 - ネットワークファイルシステム（NFS）リモートダイレクトメモリアクセス（RDMA）問題文
翻訳編集 : 自動生成

Network Working Group                                          T. Talpey
Request for Comments: 5532                                   C. Juszczak
Category: Informational                                         May 2009

     Network File System (NFS) Remote Direct Memory Access (RDMA)
                           Problem Statement

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.

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

著作権表示

著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。

Abstract

抽象

This document addresses enabling the use of Remote Direct Memory Access (RDMA) by the Network File System (NFS) protocols. NFS implementations historically incur significant overhead due to data copies on end-host systems, as well as other processing overhead. This document explores the potential benefits of RDMA to these implementations and evaluates the reasons why RDMA is especially well-suited to NFS and network file protocols in general.

ネットワークファイルシステム（NFS）プロトコルによってリモートダイレクトメモリアクセス（RDMA）の使用を可能にする。この文書アドレス。 NFSの実装では、歴史的に起因するエンドホスト・システム上のデータのコピー、ならびに他の処理オーバーヘッドに大きなオーバーヘッドを招きます。この文書では、これらの実装へのRDMAの潜在的な利点を探求し、RDMAは、特に一般的にNFSおよびネットワーク・ファイル・プロトコルによく適している理由を評価します。

Table of Contents

   1. Introduction ....................................................2
      1.1. Background .................................................3
   2. Problem Statement ...............................................4
   3. File Protocol Architecture ......................................5
   4. Sources of Overhead .............................................7
      4.1. Savings from TOE ...........................................8
      4.2. Savings from RDMA ..........................................9
   5. Application of RDMA to NFS .....................................10
   6. Conclusions ....................................................10
   7. Security Considerations ........................................11
   8. Acknowledgments ................................................12
   9. References .....................................................12
      9.1. Normative References ......................................12
      9.2. Informative References ....................................13

1. Introduction

1. はじめに

The Network File System (NFS) protocol (as described in [RFC1094], [RFC1813], and [RFC3530]) is one of several remote file access protocols used in the class of processing architecture sometimes called Network-Attached Storage (NAS).

ネットワークファイルシステム（NFS）プロトコル（[RFC1094]、[RFC1813]及び[RFC3530]に記載されているように）時々ネットワーク接続ストレージ（NAS）と呼ばれる処理アーキテクチャのクラスで使用されるいくつかのリモート・ファイル・アクセス・プロトコルの一つです。

Historically, remote file access has proven to be a convenient, cost-effective way to share information over a network, a concept proven over time by the popularity of the NFS protocol. However, there are issues in such a deployment.

歴史的に、リモートファイルへのアクセスは、ネットワーク上で情報を共有するのに便利な、費用対効果の高い方法、NFSプロトコルの普及により経時的に実績のある概念であることが証明されています。しかし、そのような展開で問題があります。

As compared to a local (direct-attached) file access architecture, NFS removes the overhead of managing the local on-disk file system state and its metadata, but interposes at least a transport network and two network endpoints between an application process and the files it is accessing. To date, this trade-off has usually resulted in a net performance loss as a result of reduced bandwidth, increased application server CPU utilization, and other overheads.

ローカル（直接接続）ファイルアクセスアーキテクチャと比較して、NFSは、ローカルディスク上のファイルシステムの状態とそのメタデータを管理するためのオーバーヘッドを除去するが、アプリケーション・プロセスとファイルとの間に少なくともトランスポートネットワーク及び2つのネットワークエンドポイントを介在しますそれがアクセスしています。現在までに、このトレードオフは、通常、帯域幅の減少の結果、当期純性能の損失が増加し、アプリケーションサーバーのCPU使用率、およびその他のオーバーヘッドをもたらしました。

Several classes of applications, including those directly supporting enterprise activities in high-performance domains such as database applications and shared clusters, have therefore encountered issues with moving to NFS architectures. While this has been due principally to the performance costs of NFS versus direct-attached files, other reasons are relevant, such as the lack of strong consistency guarantees being provided by NFS implementations.

そのようなデータベースアプリケーションと共有クラスタなどの高性能ドメインのものを直接支持企業活動を含むアプリケーションのいくつかのクラスは、したがって、NFSアーキテクチャへの移行の問題に遭遇しました。これは主に直接添付ファイルに対してNFSのパフォーマンスコストが原因であったが、他の理由は、このようなNFS実装によって提供されている強力な一貫性保証の不足など、関連しています。

Replication of local file access performance on NAS using traditional network protocol stacks has proven difficult, not because of protocol processing overheads, but because of data copy costs in the network endpoints. This is especially true since host buses are now often the main bottleneck in NAS architectures [MOG03] [CHA+01].

従来のネットワークプロトコルスタックを使用してNAS上のローカルファイルアクセス性能のレプリケーションがないため、プロトコル処理のオーバーヘッドの、しかし、ネットワークのエンドポイントでのデータコピー費のため、困難であることが判明しました。ホストバスは今、多くの場合、NASアーキテクチャの主なボトルネック[MOG03] [CHA + 01]であることから、これは特にそうです。

The External Data Representation [RFC4506] employed beneath NFS and the Remote Procedure Call (RPC) [RFC5531] can add more data copies, exacerbating the problem.

NFSおよびリモートプロシージャコール（RPC）の下に採用外部データ表現[RFC4506] [RFC5531]は、問題を悪化させ、より多くのデータのコピーを追加することができます。

Data copy-avoidance designs have not been widely adopted for a variety of reasons. [BRU99] points out that "many copy avoidance techniques for network I/O are not applicable or may even backfire if applied to file I/O". Other designs that eliminate unnecessary copies, such as [PAI+00], are incompatible with existing APIs and therefore force application changes.

データコピー回避のデザインは、広く様々な理由のために採用されていません。 [BRU99]「ネットワークのための多くのコピー回避技術I / Oが適用されないか、I / Oをファイルに適用した場合であっても裏目に出ること」と指摘しています。このような[PAI + 00]のような不要なコピーを排除する他の設計は、既存のAPIと互換性があり、したがって、アプリケーションの変更を強制します。

In recent years, an effort to standardize a set of protocols for Remote Direct Memory Access (RDMA) over the standard Internet Protocol Suite has been chartered [RDDP]. A complete IP-based RDMA protocol suite is available in the published Standards Track specifications.

近年では、標準のインターネット・プロトコル・スイートを介してリモートダイレクトメモリアクセス（RDMA）のためのプロトコルのセットを標準化するための努力は、[RDDP]チャーターされました。完全なIPベースのRDMAプロトコルスイートは、公開された標準化過程仕様で提供されています。

RDMA is a general solution to the problem of CPU overhead incurred due to data copies, primarily at the receiver. Substantial research has addressed this and has borne out the efficacy of the approach. An overview of this is the "Remote Direct Memory Access (RDMA) over IP Problem Statement" [RFC4297].

RDMAは、主に、受信機において、データコピーによる発生CPUオーバーヘッドの問題に対する一般的な解決策です。かなりの研究がこれを取り上げており、アプローチの有効性を裏付けています。この概要は、[RFC4297]「IP問題文の上にリモートダイレクトメモリアクセス（RDMA）」です。

In addition to the per-byte savings of offloading data copies, RDMA-enabled NICs (RNICS) offload the underlying protocol layers as well (e.g., TCP), further reducing CPU overhead due to NAS processing.

データ・コピーをオフロードのバイトあたりのコスト削減に加えて、RDMA対応のNIC（RNICS）はさらにによるNAS処理にCPUのオーバーヘッドを低減する、ならびに（例えば、TCP）基礎となるプロトコル層をオフロードします。

1.1. Background

1.1. バックグラウンド

The RDDP Problem Statement [RFC4297] asserts:

RDDP問題文[RFC4297]はアサート：

High costs associated with copying are an issue primarily for large scale systems ... 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.

高帯域フィードにコピーに関連した高いコストは通常、...悪オーバーヘッドをコピーすることによって影響を受けているマルチプロセッサおよびクラスタ、大規模システムのための主な問題です。データベースサーバ、ストレージサーバ、アプリケーションサーバトランザクション処理のために、電子商取引のための、およびウェブ配信、コンテンツ配信、映像配信、バックアップ、データマイニングや意思決定支援、および科学計算：このようなマシンの例としては、すべてのサーバーの種類が含まれます。

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 of copying overhead for a particular load is the same whether from few or many sessions.

そのようなサーバがほぼ独占的に集約して、通信の> 1Gビット/秒を担当している、多くの同時セッション（トランスポート接続）、サービスということに注意してください。それにもかかわらず、特定の負荷のためのオーバーヘッドをコピーするコストは、数または多数のセッションからも同じです。

Note that each of the servers listed above could be accessing their file data as an NFS client, or as NFS serving the data to such clients, or acting as both.

上記の各サーバは、NFSクライアントとしてそのファイルデータへのアクセス、またはNFSなどのクライアントにデータを提供する、またはその両方として機能することができることに注意してください。

The CPU overhead of the NFS and TCP/IP protocol stacks (including data copies or reduced copy workarounds) becomes a significant matter in these clients and servers. File access using locally attached disks imposes relatively low overhead due to the highly optimized I/O path and direct memory access afforded to the storage controller. This is not the case with NFS, which must pass data to, and especially from, the network and network processing stack to the NFS stack. Frequently, data copies are imposed on this transfer; in some cases, several such copies are imposed in each direction.

（データのコピーや縮小コピーの回避策を含む）、NFSおよびTCP / IPプロトコルスタックのCPUのオーバーヘッドは、これらのクライアントとサーバで重大な問題となります。ローカルに接続されたディスクを使用してファイルアクセスが原因の記憶制御装置に与え、高度に最適化されたI / Oパスおよびダイレクト・メモリ・アクセスに比較的低いオーバーヘッドを課します。これは、特にNFSスタックにネットワークおよびネットワーク処理スタックからのデータを渡す必要がありNFSの場合ではありません。多くの場合、データのコピーは、この転送に課されます。いくつかのケースでは、いくつかのそのようなコピーが各方向に課されます。

Copies are potentially encountered in an NFS implementation exchanging data to and from user address spaces, within kernel buffer caches, in eXternal Data Representation (XDR) marshalling and unmarshalling, and within network stacks and network drivers. Other overheads such as serialization among multiple threads of execution sharing a single NFS mount point and transport connection are additionally encountered.

コピーは、潜在的にユーザのアドレス空間へとから、カーネル・バッファ・キャッシュ内の、外部データ表現（XDR）マーシャリング及びアンマーシャリングで、ネットワークスタックおよびネットワークドライバ内にデータを交換するNFS実装に遭遇します。そのような単一のNFSマウントポイントとトランスポート接続を共有する複数の実行スレッド間でシリアル化のような他のオーバーヘッドがさらに発生しました。

Numerous upper-layer protocols achieve extremely high bandwidth and low overhead through the use of RDMA. [MAF+02] shows that the RDMA-based Direct Access File System (with a user-level implementation of the file system client) can outperform even a zero-copy implementation of NFS [CHA+01] [CHA+99] [GAL+99] [KM02]. Also, file data access implies the use of large Unequal Loss Protection (ULP) messages. These large messages tend to amortize any increase in per-message costs due to the offload of protocol processing incurred when using RNICs while gaining the benefits of reduced per-byte costs. Finally, the direct memory addressing afforded by RDMA avoids many sources of contention on network resources.

多数の上位層プロトコルは、RDMAを使用することにより、非常に高い帯域幅と低いオーバーヘッドを達成します。 [MAF + 02]（ファイルシステムクライアントのユーザーレベルの実装で）RDMAベースのダイレクトアクセスファイルシステムがNFSの偶数ゼロコピー実装を上回ることができることを示している[CHA + 01] [CHA + 99] [GAL +99] [KM02]。また、ファイルデータへのアクセスは、大きな不平等な損失保護（ULP）のメッセージを使用することを意味します。これらの大きなメッセージはRNICsを使用するときに減少バイトあたりのコストの利点を得ながら被ったプロトコル処理のオフロードのために、メッセージごとのコストの増加を償却する傾向があります。最後に、RDMAによってもたらされるダイレクトメモリアドレッシングは、ネットワークリソースの競合の多くの情報源を避けることができます。

2. Problem Statement

2.問題文

The principal performance problem encountered by NFS implementations is the CPU overhead required to implement the protocol. Primary among the sources of this overhead is the movement of data from NFS protocol messages to its eventual destination in user buffers or aligned kernel buffers. Due to the nature of the RPC and XDR protocols, the NFS data payload arrives at arbitrary alignment, necessitating a copy at the receiver, and the NFS requests are completed in an arbitrary sequence.

NFS実装が遭遇する主要なパフォーマンス上の問題は、プロトコルを実装するために必要なCPUのオーバーヘッドです。このオーバーヘッドのソースのうちプライマリユーザバッファまたは整列カーネルバッファ内のその最終的な宛先へのNFSプロトコルメッセージからのデータの移動です。 RPCとXDRプロトコルの性質のために、NFSデータペイロードは、受信機でコピーを必要とする、任意の配向に到達し、NFS要求は、任意の順序で完了されます。

The data copies consume system bus bandwidth and CPU time, reducing the available system capacity for applications [RFC4297]. To date, achieving zero-copy with NFS has required sophisticated, version- specific "header cracking" hardware and/or extensive platform-specific virtual memory mapping tricks. Such approaches become even more difficult for NFS version 4 due to the existence of the COMPOUND operation and presence of Kerberos and other security information, which further reduce alignment and greatly complicate ULP offload.

データのコピーは、アプリケーション[RFC4297]のために利用可能なシステム容量を減少させる、システムバス帯域幅とCPU時間を消費します。現在までに、NFSでゼロコピーを実現することは、ハードウェアおよび/または大規模なプラットフォーム固有の仮想メモリマッピングのトリックを洗練された、バージョン固有「割れヘッダを」必要としていました。そのようなアプローチは、原因さらに、アライメントを減らし、大幅ULPオフロードを複雑複合操作やKerberosなどのセキュリティ情報の存在の有無にもNFSバージョン4のためのより困難になります。

Furthermore, NFS is challenged by high-speed network fabrics such as 10 Gbits/s Ethernet. Performing even raw network I/O such as TCP is an issue at such speeds with today's hardware. The problem is fundamental in nature and has led the IETF to explore RDMA [RFC4297].

さらに、NFSは、10ギガビット/秒イーサネット（登録商標）のような高速ネットワークファブリックによって挑戦されます。 TCPのようにも生のネットワークI / Oを実行すると、現在のハードウェアと、そのような速度で問題です。問題は、自然の中で基本的であるとRDMA [RFC4297]を探索するためにIETFをリードしてきました。

Zero-copy techniques benefit file protocols extensively, as they enable direct user I/O, reduce the overhead of protocol stacks, provide perfect alignment into caches, etc. Many studies have already shown the performance benefits of such techniques [SKE+01] [DCK+03] [FJNFS] [FJDAFS] [KM02] [MAF+02].

彼らは直接のユーザI / Oを有効にするとゼロコピー技術等、キャッシュに完全なアライメントを提供し、プロトコルスタックのオーバーヘッドを削減する、広範囲にファイルプロトコルに利益をもたらす多くの研究はすでに[そのような技術[SKE + 01]のパフォーマンス上の利点を示していますDCK + 03] [FJNFS] [FJDAFS] [KM02] [MAF + 02]。

RDMA is compelling here for another reason; hardware-offloaded networking support in itself does not avoid data copies, without resorting to implementing part of the NFS protocol in the Network Interface Card (NIC). Support of RDMA by NFS enables the highest performance at the architecture level rather than by implementation; this enables ubiquitous and interoperable solutions.

RDMAは、別の理由でここに説得力があります。ハードウェアオフロードネットワークインタフェースカード（NIC）でNFSプロトコルの一部を実装するに頼ることなく、データのコピーを回避していない自体にネットワークサポート。 NFSによってRDMAのサポートは、アーキテクチャレベルではなく実装することにより最高の性能を可能にします。これはユビキタスと相互運用可能なソリューションを可能にします。

By providing file access performance equivalent to that of local file systems, NFS over RDMA will enable applications running on a set of client machines to interact through an NFS file system, just as applications running on a single machine might interact through a local file system.

ローカルファイルシステムのものにファイルアクセス性能と同等を提供することにより、RDMAを超えるNFSは、単一のマシン上で実行されるアプリケーションは、ローカルファイルシステムを介して相互作用かもしれないと同じように、NFSファイル・システムを介して対話するクライアント・マシンのセット上で動作するアプリケーションを可能にします。

3. File Protocol Architecture

3.ファイルプロトコルアーキテクチャ

NFS runs as an Open Network Computing (ONC) RPC [RFC5531] application. Being a file access protocol, NFS is very "rich" in data content (versus control information).

NFSは、オープンネットワークコンピューティング（ONC）RPC [RFC5531]のアプリケーションとして実行されます。ファイルアクセスプロトコルなので、NFSは、（制御情報対）データ内容で非常に「リッチ」です。

NFS messages can range from very small (under 100 bytes) to very large (from many kilobytes to a megabyte or more). They are all contained within an RPC message and follow a variable-length RPC header. This layout provides an alignment challenge for the data items contained in an NFS call (request) or reply (response) message.

NFSメッセージは、（多くのキロバイトからメガバイト以上）、非常に大きなに非常に小さいから（100バイト未満）の範囲とすることができます。彼らは、すべてのRPCメッセージ内に含まれると可変長RPCヘッダに追従しています。このレイアウトは、NFSコール（要求）または応答（レスポンス）メッセージに含まれるデータ項目のアライメント挑戦を提供します。

In addition to the control information in each NFS call or reply message, sometimes there are large "chunks" of application file data, for example, read and write requests. With NFS version 4 (due to the existence of the COMPOUND operation), there can be several of these data chunks interspersed with control information.

各NFSコールまたは応答メッセージ内の制御情報に加えて、時々、例えば、読み取りおよび書き込み要求をアプリケーション・ファイル・データの大きな「チャンク」が存在します。 NFSバージョン4（複合操作の有無に起因する）と、制御情報が散在これらのデータチャンクのいくつかがあり得ます。

ONC RPC is a remote procedure call protocol that has been run over a variety of transports. Most implementations today use UDP or TCP. RPC messages are defined in terms of an eXternal Data Representation (XDR) [RFC4506], which provides a canonical data representation across a variety of host architectures. An XDR data stream is conveyed differently on each type of transport. On UDP, RPC messages are encapsulated inside datagrams, while on a TCP byte stream, RPC messages are delineated by a record-marking protocol. An RDMA transport also conveys RPC messages in a unique fashion that must be fully described if client and server implementations are to interoperate.

ONC RPCは、トランスポートのさまざま上で実行されたリモートプロシージャコールプロトコルです。ほとんどの実装今日は、UDPまたはTCPを使用します。 RPCメッセージは、ホスト・アーキテクチャのさまざま横切るカノニカルデータ表現を提供する外部データ表現（XDR）[RFC4506]で定義されています。 XDRデータストリームは、トランスポートの種類ごとに異なって搬送されます。 TCPのバイトストリーム上で、RPCメッセージが記録マーキングプロトコルによって描写されている間、UDPで、RPCメッセージは、データグラムの中にカプセル化します。 RDMAトランスポートは、クライアントとサーバーの実装が相互運用のであれば十分に説明しなければならないユニークなファッションにRPCメッセージを伝えます。

The RPC transport is responsible for conveying an RPC message from a sender to a receiver. An RPC message is either an RPC call from a client to a server, or an RPC reply from the server back to the client. An RPC message contains an RPC call header followed by arguments if the message is an RPC call, or an RPC reply header followed by results if the message is an RPC reply. The call header contains a transaction ID (XID) followed by the program and procedure number as well as a security credential. An RPC reply header begins with an XID that matches that of the RPC call message, followed by a security verifier and results. All data in an RPC message is XDR encoded.

RPCトランスポートは、送信機から受信機にRPCメッセージを搬送するための責任があります。 RPCメッセージは、クライアントからサーバーへのRPC呼び出し、またはバックサーバからクライアントへのRPC応答のいずれかです。メッセージは、RPC応答である場合、メッセージは、RPCコール、又は結果に続くRPC応答ヘッダである場合、RPCメッセージは、引数に続くRPC呼び出しヘッダを含んでいます。コールヘッダは、プログラムと手順番号ならびにセキュリティ証明書が続くトランザクションID（XID）を含みます。 RPC応答ヘッダは、セキュリティ検証し、その結果、続いてRPCコールメッセージと一致するXID、始まります。 RPCメッセージ内のすべてのデータがXDRは、符号化されています。

The encoding of XDR data into transport buffers is referred to as "marshalling", and the decoding of XDR data contained within transport buffers and into destination RPC procedure result buffers, is referred to as "unmarshalling". Therefore, the process of marshalling takes place at the sender of any particular message, be it an RPC request or an RPC response. Unmarshalling, of course, takes place at the receiver.

トランスポートバッファにXDRデータの符号化を「マーシャリング」と呼ばれ、トランスポートバッファ内と宛先RPC手順結果バッファに含まれるXDRデータの復号化は、「アンマーシャリング」と呼ばれます。したがって、マーシャリングのプロセスは、任意の特定のメッセージの送信者で起こる、それはRPC要求またはRPC応答です。アンマーシャリングは、当然のことながら、受信機で行われます。

Normally, any bulk data is moved (copied) as a result of the unmarshalling process, because the destination address is not known until the RPC code receives control and subsequently invokes the XDR unmarshalling routine. In other words, XDR-encoded data is not self-describing, and it carries no placement information. This results in a data copy in most NFS implementations.

RPCコードは制御を受け取り、その後XDRアンマーシャリングルーチンを呼び出すまで、宛先アドレスが不明であるため、通常、任意のバルクデータは、非整列化プロセスの結果として、（コピー）に移動されます。換言すれば、XDRエンコードされたデータは、自己記述型ではない、それは何の配置情報を搬送しません。これは、ほとんどのNFS実装でデータのコピーになります。

One mechanism by which the RPC layer may overcome this is for each request to include placement information, to be used for direct placement during XDR encode. This "write chunk" can avoid sending bulk data inline in an RPC message and generally results in one or more RDMA Write operations.

RPC層はこれを克服し得る1つのメカニズムは、XDRエンコード中に直接配置するために使用される配置情報を含むように各要求のためのものです。この「ライト・チャンクは、」RPCメッセージに大量のデータをインラインで送信避け、一般に、1つ以上のRDMA書き込み操作になりことができます。

Similarly, a "read chunk", where placement information referring to bulk data that may be directly fetched via one or more RDMA Read operations during XDR decode, may be conveyed. The "read chunk" will therefore be useful in both RPC calls and replies, while the "write chunk" is used solely in replies.

同様に、配置情報はXDRデコード中に1つ以上のRDMA読み取り操作を介して直接フェッチであってもよいバルクデータを参照し、「チャンクを読み込む」、搬送されてもよいです。「ライト・チャンクが」回答にのみ使用されている間、「読みチャンクは、」そのため、RPCコールと回答の両方に有用であろう。

These "chunks" are the key concept in an existing proposal [RPCRDMA]. They convey what are effectively pointers to remote memory across the network. They allow cooperating peers to exchange data outside of XDR encodings but still use XDR for describing the data to be transferred. And, finally, through use of XDR they maintain a large degree of on-the-wire compatibility.

これらの「チャンク」は、既存の提案[RPCRDMA]で重要な概念です。彼らは効果的にネットワーク経由でのリモートメモリへのポインタであるものを伝えます。彼らは、XDRエンコーディングの外にデータを交換するが、まだ転送すべきデータを記述するためのXDRを使用するピア協働を可能にします。そして、最後に、XDRを使用して、彼らは、オン・ワイヤー互換性の大きな程度を維持します。

The central concept of the RDMA transport is to provide the additional encoding conventions to convey this placement information in transport-specific encoding, and to modify the XDR handling of bulk data.

RDMA輸送の中心的な概念は、トランスポート固有のエンコーディングで、この配置情報を伝えるために、バルクデータのXDRの取り扱いを変更するために、追加のエンコーディング規則を提供することです。

Block Diagram

ブロック図

   +------------------------+-----------------------------------+
   |         NFS            |            NFS + RDMA             |
   +------------------------+----------------------+------------+
   |           Operations / Procedures             |            |
   +-----------------------------------------------+            |
   |                   RPC/XDR                     |            |
   +--------------------------------+--------------+            |
   |       Stream Transport         |      RDMA Transport       |
   +--------------------------------+---------------------------+

4. Sources of Overhead

オーバーヘッドの4元

Network and file protocol costs can be categorized as follows:

次のようにネットワークとファイルプロトコルコストを分類できます。

o per-byte costs - data touching costs such as checksum or data copy. Today's network interface hardware commonly offloads the checksum, which leaves the other major source of per-byte overhead, data copy.

バイトあたりのコスト○ - データなど、チェックサムやデータコピーなどの費用に触れます。今日のネットワーク・インターフェース・ハードウェアは、一般的にバイトあたりのオーバーヘッド、データコピーの他の主要な供給源を残しチェックサムを、オフロードします。

o per-packet costs - interrupts and lower-layer processing (LLP). Today's network interface hardware also commonly coalesce interrupts to reduce per-packet costs.

割り込みと下位層処理（LLP） - パケット当たりのコストO。今日のネットワーク・インターフェース・ハードウェアはまた、一般的に、パケット単位のコストを削減するために割り込みを合体します。

o per-message (request or response) costs - LLP and ULP processing.

LLPとULP処理 - ごとのメッセージ（要求または応答）、コストO。

Improvement from optimization becomes more important if the overhead it targets is a larger share of the total cost. As other sources of overhead, such as the checksumming and interrupt handling above are eliminated, the remaining overheads (primarily data copy) loom larger.

それは対象オーバーヘッドは総コストの大きな割合であれば、最適化の改善がより重要になります。他のこのようなチェックサムのようなオーバーヘッドの発生源、および上記割り込み処理が排除されるように、残りのオーバーヘッドは、（主にデータコピー）が大きく織機。

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 at or above 1 Gbit/s.

ネットワーク帯域幅は、CPUやメモリ帯域幅に比べて大きい時はいつでもコピーはコピー二回バスを横断して、ネットワーク処理のオーバーヘッドが高いです。一般的に、今日のエンドシステムで、効果がでたり1ギガビット/秒以上のネットワーク速度で観測可能です。

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 [RFC4297].

一般的な質問は、CPUの処理能力の増加は、ネットワークI / Oの高い処理コストの問題を軽減するかどうかです。答えはノー、それは問題であるメモリ帯域幅です。 CPUは、メモリ[RFC4297]を待っているそのほとんどの時間を費やしている場合はより高速なCPUは役立ちません。

TCP offload engine (TOE) technology aims to offload the CPU by moving TCP/IP protocol processing to the NIC. However, TOE technology by itself does nothing to avoid necessary data copies within upper-layer protocols. [MOG03] provides a description of the role TOE can play in reducing per-packet and per-message costs. Beyond the offloads commonly provided by today's network interface hardware, TOE alone (without RDMA) helps in protocol header processing, but this has been shown to be a minority component of the total protocol processing overhead. [CHA+01]

TCPオフロードエンジン（TOE）テクノロジは、NICにTCP / IPプロトコル処理を移動することにより、CPUの負荷を軽減することを目指しています。しかし、それだけでTOE技術は、上位層プロトコル内の必要なデータのコピーを避けるために何もしません。 [MOG03] TOEは、パケットごとの削減とメッセージごとのコストで遊ぶことができる役割の説明を提供します。一般的に、今日のネットワーク・インターフェース・ハードウェアによって提供されるオフロードを越えて、（RDMAなしで）単独でTOEは、プロトコルヘッダ処理に役立つが、これは、全プロトコル処理オーバーヘッドの少数成分であることが示されています。 [CHA + 01]

Numerous software approaches to the optimization of network throughput have been made. Experience has shown that network I/O interacts with other aspects of system processing such as file I/O and disk I/O [BRU99] [CHU96]. Zero-copy optimizations based on page remapping [CHU96] can be dependent upon machine architecture, and are not scalable to multi-processor architectures. Correct buffer alignment and sizing together are needed to optimize the performance of zero-copy movement mechanisms [SKE+01]. The NFS message layout described above does not facilitate the splitting of headers from data nor does it facilitate providing correct data buffer alignment.

ネットワークスループットの最適化に多くのソフトウェアのアプローチがなされてきました。経験は、I / Oは、このようなI / O [BRU99] [CHU96]ファイルI / Oやディスクなどのシステム処理の他の側面と相互作用するネットワークを示しています。 [CHU96]再マッピングページに基づいてゼロコピーの最適化は、マシンアーキテクチャに依存すること、およびマルチプロセッサ・アーキテクチャにスケーラブルではありませんすることができます。正しいバッファアラインメントと一緒にサイズがゼロコピー移動機構[SKE + 01]の性能を最適化するために必要とされます。上記NFSメッセージレイアウトデータからヘッダの分割を容易にしておらず、正しいデータバッファアライメントを提供容易ありません。

4.1. Savings from TOE

4.1. TOEからの貯蓄

The expected improvement of TOE specifically for NFS protocol processing can be quantified and shown to be fundamentally limited. [SHI+03] presents a set of "LAWS" parameters that serve to illustrate the issues. In the TOE case, the copy cost can be viewed as part of the application processing "a". Application processing increases the LAWS "gamma", which is shown by the paper to result in a diminished benefit for TOE.

具体的にはNFSプロトコル処理のためにTOEの期待される改善を定量化し、基本的に制限されることを示すことができます。 [SHI + 03]の問題を説明するのに役立つ「法律」パラメータのセットを提示します。 TOEの場合に、コピーのコストは、アプリケーション処理「A」の一部とみなすことができます。アプリケーション処理は、TOEの減少の利益をもたらすこと紙によって示されている法律「ガンマ」を増加させます。

For example, if the overhead is 20% TCP/IP, 30% copy, and 50% real application work, then gamma is 80/20 or 4, which means the maximum benefit of TOE is 1/gamma, or only 25%.

オーバーヘッドは20％TCP / IP、30％のコピー、および50％の実際の塗布作業である場合、例えば、次にガンマはTOEの最大の利点は、1 /ガンマ、またはわずか25％であることを意味する、80/20または4です。

For RDMA (with embedded TOE) and the same example, the "overhead" (o) offloaded or eliminated is 50% (20% + 30%). Therefore, in the RDMA case, gamma is 50/50 or 1, and the inverse gives the potential benefit of 1 (100%), a factor of two.

（埋め込みTOE付き）RDMAと同様、例えば、 "オーバーヘッド"（O）は、オフロードまたは排除50％（20％+ 30％）です。したがって、RDMAの場合に、ガンマは50/50または1であり、そして逆1（100％）の潜在的な利点、2倍を与えます。

CPU Overhead Reduction Factor

CPUのオーバーヘッド削減ファクター

               No Offload   TCP Offload   RDMA Offload
               -----------+-------------+-------------
                  1.00x        1.25x         2.00x

The analysis in the paper shows that RDMA could improve throughput by the same factor of two, even when the host is (just) powerful enough to drive the full network bandwidth without RDMA. It can also be shown that the speedup may be higher if network bandwidth grows faster than Moore's Law, although the higher benefits will apply to a narrow range of applications.

論文の分析では、ホストがRDMAせずに完全なネットワーク帯域幅を駆動するのに十分な（ちょうど）の強力な場合であっても、RDMAは、2の同じ要因により、スループットを向上させることができることを示しています。また、ネットワークの帯域幅がムーアの法則よりも速く成長している場合、より高い利益がアプリケーションの狭い範囲に適用されますが、スピードアップは、高くなる可能性がありことを示すことができます。

4.2. Savings from RDMA

4.2. RDMAから貯蓄

Performance measurements directly comparing an NFS-over-RDMA prototype with conventional network-based NFS processing are described in [CAL+03]. Comparisons of Read throughput and CPU overhead were performed on two types of Gigabit Ethernet adapters, one type being a conventional adapter, and another type with RDMA capability. The prototype RDMA protocol performed all transfers via RDMA Read. The NFS layer in the study was measured while performing read transfers, varying the transfer size and readahead depth across ranges used by typical NFS deployments.

直接従来のネットワークベースのNFS処理とNFSオーバーRDMAプロトタイプを比較性能測定は、[CAL + 03]に記載されています。読み取りスループットとCPUオーバーヘッドの比較は、2つのギガビット・イーサネット・アダプタの種類は、1種は、従来のアダプタであること、及びRDMA能力を有する別のタイプで行いました。プロトタイプのRDMAプロトコルはRDMAリードを経由してすべての転送を行いました。リード転送を行いながら研究でNFS層は、典型的なNFS配備によって使用範囲を横切って転送サイズと先読み深さを変化させ、測定されました。

In these results, conventional network-based throughput was severely limited by the client's CPU being saturated at 100% for all transfers. Read throughput reached no more than 60 MBytes/s.

これらの結果では、従来のネットワークベースのスループットが厳しく全ての転送のために100％で飽和され、クライアントのCPUによって制限されました。読むスループットはせいぜい60メガバイト/秒に達しました。

I/O Type Size Read Throughput CPU Utilization Conventional 2 KB 20 MB/s 100% Conventional 16 KB 40 MB/s 100% Conventional 256 KB 60 MB/s 100%

I / Oタイプサイズ読み取りスループットCPU使用率従来の2キロバイト20メガバイト/秒、100％の従来の16キロバイト40メガバイト/秒、100％の従来の256キロバイト60メガバイト/秒の100％

However, over RDMA, throughput rose to the theoretical maximum throughput of the platform, while saturating the single-CPU system only at maximum throughput.

唯一最大のスループットで単一CPUシステムを飽和させながらしかし、RDMAの上に、スループットは、プラットフォームの理論的な最大スループットに上昇しました。

I/O Type Size Read Throughput CPU Utilization RDMA 2 KB 10 MB/s 45% RDMA 16 KB 40 MB/s 70% RDMA 256 KB 100 MB/s 100%

I / OタイプサイズリードスループットCPU使用率RDMA 2キロバイト10メガバイト/秒の45％RDMA 16キロバイト40メガバイト/秒の70％RDMA 256キロバイト100メガバイト/ sの100％

The lower relative throughput of the RDMA prototype at the small blocksize may be attributable to the RDMA Read imposed by the prototype protocol, which reduced the operation rate since it introduces additional latency. As well, it may reflect the relative increase of per-packet setup costs within the DMA portion of the transfer.

小さなブロックサイズでRDMAプロトタイプの低い相対スループットは、追加の遅延を導入するので、稼働率が低下プロトタイププロトコルによって課さRDMA読み取りに起因し得ます。同様に、それは転送のDMA部分内のパケットごとのセットアップ費の相対的な増加を反映してもよいです。

5. Application of RDMA to NFS

NFSへのRDMAの5.アプリケーション

Efficient file protocols require efficient data positioning and movement. The client system knows the client memory address where the application has data to be written or wants read data deposited. The server system knows the server memory address where the local file system will accept write data or has data to be read. Neither peer however is aware of the others' data destination in the current NFS, RPC, or XDR protocols. Existing NFS implementations have struggled with the performance costs of data copies when using traditional Ethernet transports.

効率的なファイルプロトコルは、効率的なデータの位置と動きを必要としています。クライアントシステムは、アプリケーションが書き込むデータを持っているか、堆積読み取ったデータを望んでいるクライアントのメモリアドレスを知っています。サーバ・システムは、ローカルファイルシステムは、書き込みデータを受け入れるか、読み込むべきデータを持っていますサーバーのメモリアドレスを知っています。どちらのピアは、しかしながら、現在のNFS、RPC、またはXDRプロトコル内の他のデータの送信先を認識しています。従来のイーサネットトランスポートを使用した場合、既存のNFSの実装では、データ・コピーのパフォーマンスコストで苦労しています。

With the onset of faster networks, the network I/O bottleneck will worsen. Fortunately, new transports that support RDMA have emerged. RDMA excels at bulk transfer efficiency; it is an efficient way to deliver direct data placement and remove a major part of the problem: data copies. RDMA also addresses other overheads, e.g., underlying protocol offload, and offers separation of control information from data.

より高速なネットワークの開始と、ネットワークI / Oのボトルネックが悪化します。幸いなことに、RDMAをサポートする新しいトランスポートが浮上しています。 RDMAは、バルク転送効率に優れます。データ・コピー：それは直接データ配置を提供し、問題の大部分を除去するための効率的な方法です。 RDMAは、プロトコルオフロードの基礎となる、例えば、他のオーバーヘッドに対処し、データから制御情報の分離を提供します。

The current NFS message layout provides the performance-enhancing opportunity for an NFS-over-RDMA protocol that separates the control information from data chunks while meeting the alignment needs of both. The data chunks can be copied "directly" between the client and server memory addresses above (with a single occurrence on each memory bus) while the control information can be passed "inline". [RPCRDMA] describes such a protocol.

現在のNFSメッセージのレイアウトは、両方の位置合わせの必要性を満たしながらデータチャンクからの制御情報を分離NFSオーバーRDMAプロトコルの性能向上の機会を提供します。制御情報は、「インライン」を渡すことができながら、データチャンクは、「直接」とは、上記クライアントとサーバのメモリアドレスとの間（各メモリ・バス上の単一の発生に）コピーすることができます。【RPCRDMAようなプロトコルを記述する。

6. Conclusions

6.結論

NFS version 4 [RFC3530] has been granted "Proposed Standard" status. The NFSv4 protocol was developed along several design points, important among them: effective operation over wide-area networks, including the Internet itself; strong security integrated into the protocol; extensive cross-platform interoperability including integrated locking semantics compatible with multiple operating systems; and (this is key), protocol extension.

NFSバージョン4 [RFC3530]は、「提案標準」ステータスが付与されています。 NFSv4のプロトコルは、それらの中で重要ないくつかのデザインのポイントに沿って開発されました：広域ネットワークを介した効果的な運用、インターネット自体を含みます。プロトコルに統合され、強力なセキュリティ。複数のオペレーティングシステムと互換性のある統合されたロッキング・セマンティクスを含む広範囲のクロスプラットフォームの相互運用。そして、プロトコル拡張（これはキーです）。

NFS version 4 is an excellent base on which to add the needed performance enhancements and improved semantics described above. The minor versioning support defined in NFS version 4 was designed to support protocol improvements without disruption to the installed base [NFSv4.1]. Evolutionary improvement of the protocol via minor

NFSバージョン4は、上述した必要な性能の強化および改善されたセマンティクスを追加する上で優れた塩基です。 NFSバージョン4で定義されたマイナーバージョンのサポートは、インストールベース【NFSv4.1]を中断することなく、プロトコルの改善をサポートするように設計しました。マイナー介したプロトコルの進化改良

versioning is a conservative and cautious approach to current and future problems and shortcomings.

バージョン管理は、現在および将来の問題や欠点に保守的で慎重なアプローチです。

Many arguments can be made as to the efficacy of the file abstraction in meeting the future needs of enterprise data service and the Internet. Fine grained Quality of Service (QoS) policies (e.g., data delivery, retention, availability, security, etc.) are high among them.

多くの引数は、エンタープライズ・データ・サービスとインターネットの将来のニーズを満たす上で、ファイルの抽象化の有効性とすることができます。きめの細かいサービス品質（QoS）ポリシー（例えば、データ配信、保持、可用性、セキュリティ、など）は、それらの間で高いです。

It is vital that the NFS protocol continue to provide these benefits to a wide range of applications, without its usefulness being compromised by concerns about performance and semantic inadequacies. This can reasonably be addressed in the existing NFS protocol framework. A cautious evolutionary improvement of performance and semantics allows building on the value already present in the NFS protocol, while addressing new requirements that have arisen from the application of networking technology.

NFSプロトコルは、その有用性は、パフォーマンスとセマンティック不備についての懸念によって損なわれることなく、アプリケーションの広い範囲にこれらの利点を提供し続けることが重要です。これは、合理的に、既存のNFSプロトコルの枠組みで対処することができます。ネットワーク技術の適用から生じた新たな要件に対処しながら、パフォーマンスと意味論の慎重な進化の改善は、NFSプロトコルに既に存在している価値に構築できます。

7. Security Considerations

7.セキュリティの考慮事項

The NFS protocol, in conjunction with its layering on RPC, provides a rich and widely interoperable security model to applications and systems. Any layering of NFS-over-RDMA transports must address the NFS security requirements, and additionally must ensure that no new vulnerabilities are introduced. For RDMA, the integrity, and any privacy, of the data stream are of particular importance.

NFSプロトコルは、そのは、RPCに重ねると連携して、アプリケーションやシステムに豊富で、広く相互運用可能なセキュリティモデルを提供します。 NFSオーバーRDMAトランスポートのいずれかのレイヤーは、NFSのセキュリティ要件に対応する必要があり、さらに新たな脆弱性が導入されていないことを確認する必要があります。 RDMAのために、データ・ストリームの整合性、および任意のプライバシーは、特に重要です。

The core goals of an NFS-to-RDMA binding are to reduce overhead and to enable high performance. To support these goals while maintaining required NFS security protection presents a special challenge. Historically, the provision of integrity and privacy have been implemented within the RPC layer, and their operation requires local processing of messages exchanged with the RPC peer. This processing imposes memory and processing overhead on a per-message basis, exactly the overhead that RDMA is designed to avoid.

NFSツーRDMA結合のコアの目標は、オーバーヘッド削減し、高い性能を可能にするためです。必要なNFSのセキュリティ保護を維持しながら、これらの目標をサポートするために特別な挑戦を提示しています。歴史的に、整合性とプライバシーの提供は、RPC層内に実装されており、そしてその動作は、RPCピアと交換されたメッセージのローカル処理が必要となります。この処理は、RDMAを回避するように設計されて正確にオーバーヘッド、メッセージごとにメモリと処理のオーバーヘッドを課します。

Therefore, it is a requirement that the RDMA transport binding provide a means to delegate the integrity and privacy processing to the RDMA hardware, in order to maintain the high level of performance desired from the approach, while simultaneously providing the existing highest levels of security required by the NFS protocol. This in turn requires a means by which the RPC layer may invoke these services from the RDMA provider, and for the NFS layer to negotiate their use end-to-end.

したがって、同時に必要なセキュリティの既存の最高レベルを提供しながら、結合RDMA転送は、アプローチから所望の性能の高いレベルを維持するために、RDMAハードウェアに完全性およびプライバシー処理を委任するための手段を提供する必要条件でありますNFSプロトコルによる。これは、順番にRPC層はRDMAプロバイダからこれらのサービスを呼び出すことができる手段を必要とし、NFS層のためのその使用、エンドツーエンドを交渉します。

The "Channel Binding" concept [RFC5056] together with "IPsec Channel Connection Latching" [BTNSLATCH] provide a means by which the RPC and NFS layers may delegate their session protection to the lower RDMA layers. An extension to the RPCSEC_GSS protocol [RFC5403] may be employed to negotiate the use of these bindings, and to establish the shared secrets necessary to protect the sessions.

一緒に「IPsecのチャネル接続がラッチ」と「チャネルバインディング」の概念[RFC5056]は[BTNSLATCH] RPCとNFS層が下位RDMA層にそのセッション保護を委任することができる手段を提供します。 RPCSEC_GSSプロトコル[RFC5403]の拡張機能は、これらのバインディングの使用を交渉するために、およびセッションを保護するために必要な共有秘密を確立するために使用することができます。

The protocol described in [RPCRDMA] specifies the use of these mechanisms, and they are required to implement the protocol.

【RPCRDMA]に記載されているプロトコルは、これらのメカニズムの使用を指定し、それらは、プロトコルを実装するために必要とされます。

An additional consideration is protection of the integrity and privacy of local memory by the RDMA transport itself. The use of RDMA by NFS must not introduce any vulnerabilities to system memory contents, or to memory owned by user processes. These protections are provided by the RDMA layer specifications, and specifically their security models. It is required that any RDMA provider used for NFS transport be conformant to the requirements of [RFC5042] in order to satisfy these protections.

追加の考慮事項は、RDMA輸送自体によってローカルメモリの整合性とプライバシーの保護です。 NFSによるRDMAを使用すると、システムメモリの内容に、またはユーザーのプロセスが所有しているメモリへの任意の脆弱性を導入してはなりません。これらの保護は、RDMA層の仕様、具体的には、彼らのセキュリティモデルによって提供されています。 NFSの輸送のために使用される任意のRDMAプロバイダがこれらの保護を満たすために[RFC5042]の要件に適合することが要求されます。

8. Acknowledgments

8.謝辞

The authors wish to thank Jeff Chase who provided many useful suggestions.

著者は、多くの有用な提案を提供しジェフ・チェイスに感謝したいです。

9. References

9.参考文献

9.1. Normative References

9.1. 引用規格

[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.

[RFC3530] Shepler、S.、キャラハン、B.、ロビンソン、D.、Thurlow、R.、Beame、C.、アイスラー、M.、およびD. Noveck、 "ネットワークファイルシステム（NFS）バージョン4プロトコル"、 RFC 3530、2003年4月。

[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, May 2009.

[RFC5531] Thurlow、R.、 "RPC：リモートプロシージャコールプロトコル仕様バージョン2"、RFC 5531、2009年5月。

[RFC4506] Eisler, M., Ed., "XDR: External Data Representation Standard", STD 67, RFC 4506, May 2006.

[RFC4506]アイスラー、M.、エド、 "XDR：外部データ表現標準"。、STD 67、RFC 4506、2006年5月。

[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, June 1995.

[RFC1813]キャラハン、B.、ポロウスキー、B.、およびP.ストーバック、 "NFSバージョン3プロトコル仕様"、RFC 1813、1995年6月。

[RFC5403] Eisler, M., "RPCSEC_GSS Version 2", RFC 5403, February 2009.

[RFC5403]アイスラー、M.、 "RPCSEC_GSSバージョン2"、RFC 5403、2009年2月。

[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.

"チャネルを確保するチャネルバインディングの使用について" [RFC5056]ウィリアムズ、N.、RFC 5056、2007年11月。

[RFC5042] Pinkerton, J. and E. Deleganes, "Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security", RFC 5042, October 2007.

[RFC5042]ピンカートン、J.およびE. Deleganes、 "直接データ配置プロトコル（DDP）/リモートダイレクトメモリアクセスプロトコル（RDMAP）セキュリティ"、RFC 5042、2007年10月。

9.2. Informative References

9.2. 参考文献

[BRU99] J. Brustoloni, "Interoperation of copy avoidance in network and file I/O", in Proc. INFOCOM '99, pages 534- 542, New York, NY, Mar. 1999., IEEE. Also available from http://www.cs.pitt.edu/~jcb/publs.html.

PROCで【BRU99] J. Brustoloni、 "ネットワークおよびファイルI / Oの中にコピー回避の相互運用"、。インフォコム'99、ページ534- 542、ニューヨーク、NY、3月1999、IEEE。またhttp://www.cs.pitt.edu/~jcb/publs.htmlから入手できます。

[BTNSLATCH] Williams, N., "IPsec Channels: Connection Latching", Work in Progress, November 2008.

[BTNSLATCH]ウィリアムズ、N.、 "IPsecのチャンネル：接続ラッチ"、進歩、2008年11月の作業。

[CAL+03] B. Callaghan, T. Lingutla-Raj, A. Chiu, P. Staubach, O. Asad, "NFS over RDMA", in Proceedings of ACM SIGCOMM Summer 2003 NICELI Workshop.

[CAL + 03] B.キャラハン、T. Lingutla-ラジ、A.チウ、P.ストーバック、O.アサド、 "RDMA上NFS"、ACM SIGCOMM 2003年夏NICELIワークショップの議事録です。

[CHA+01] J. S. Chase, A. J. Gallatin, K. G. Yocum, "Endsystem optimizations for high-speed TCP", IEEE Communications, 39(4):68-74, April 2001.

[CHA + 01] J. S.チェイス、A. J.ガラティン、K. G. Yocum、 "高速TCPのためのエンドシステムの最適化"、IEEE通信、39（4）：68-74、2001年4月。

[CHA+99] J. S. Chase, D. C. Anderson, A. J. Gallatin, A. R. Lebeck, K. G. Yocum, "Network I/O with Trapeze", in 1999 Hot Interconnects Symposium, August 1999.

[CHA + 99] 1999ホットインターコネクトシンポジウム、1999年8月J. S.チェイス、D. C.アンダーソン、 "ブランコとネットワークI / O" A. J.ガラティン、A. R. Lebeck、K. G. Yocum、、。

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

【CHU96] H.K.チュー、 "SolarisのでゼロコピーTCP"、PROC。 USENIX 1996年次技術会議、サンディエゴ、CA、1996年1月の。

[DCK+03] M. DeBergalis, P. Corbett, S. Kleiman, A. Lent, D. Noveck, T. Talpey, M. Wittle, "The Direct Access File System", in Proceedings of 2nd USENIX Conference on File and Storage Technologies (FAST '03), San Francisco, CA, March 31 - April 2, 2003.

[DCK + 03]ファイルに第2回USENIX会議の議事録におけるM. DeBergalis、P.コーベット、S.クレイマン、A.レント、D. Noveck、T. Talpey、M. Wittle、 "ダイレクト・アクセス・ファイル・システム"、およびストレージテクノロジーズ（FAST '03）、サンフランシスコ、CA、2003年3月31日から4月2日まで。

[FJDAFS] Fujitsu Prime Software Technologies, "Meet the DAFS Performance with DAFS/VI Kernel Implementation using cLAN", available from http://www.pst.fujitsu.com/english/dafsdemo/index.html, 2001.

[FJDAFS]富士通プライムソフトテクノロジ、2001、http://www.pst.fujitsu.com/english/dafsdemo/index.htmlから入手できる、「一族使用してDAFS / VIカーネルの実装とDAFS性能を満たします」。

[FJNFS] Fujitsu Prime Software Technologies, "An Adaptation of VIA to NFS on Linux", available from http://www.pst.fujitsu.com/english/nfs/index.html, 2000.

[FJNFS]富士通プライムソフトテクノロジ、http://www.pst.fujitsu.com/english/nfs/index.htmlから入手可能な "Linux上でのNFSへのVIAの適応"、2000年。

[GAL+99] A. Gallatin, J. Chase, K. Yocum, "Trapeze/IP: TCP/IP at Near-Gigabit Speeds", 1999 USENIX Technical Conference (Freenix Track), June 1999.

[GAL + 99] A.ギャラティン、J.チェイス、K. Yocum、 "ブランコ/ IP：ニアギガビットの速度でTCP / IP"、1999 USENIX技術会議（FREENIXトラック）、1999年6月。

[KM02] 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.

USENIX BSDCon 2002会議、サンフランシスコ、CA、2月11-14、2002年の議事録で[KM02] K. Magoutis、 "ダイレクト・アクセス・ファイル・システムFreeBSD用（DAFS）カーネルサーバの設計と実装"、。

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

[MAF + 02] K. Magoutis、S. Addetia、A.フェドロワ、M.セルツァー、J.チェイス、D.ガラティン、R.キズリー、R. Wickremesinghe、E.多弁家、「構造とダイレクトアクセスファイルのパフォーマンスシステム（DAFS）」、2002 USENIX年次技術会議議事録、モントレー、カリフォルニア州、6月9-14、2002インチ

[MOG03] J. Mogul, "TCP offload is a dumb idea whose time has come", 9th Workshop on Hot Topics in Operating Systems (HotOS IX), Lihue, HI, May 2003. USENIX.

[MOG03] J.ムガール人は、オペレーティングシステムのホットな話題で第9回ワークショップ（HotOS IX）、リフエ、ハワイ、2003年5月USENIX「TCPオフロードは、その時来ているダムアイデアです」。

[NFSv4.1] Shepler, S., Eisler, M., and D. Noveck, "NFSv4 Minor Version 1", Work in Progress, September 2008.

[NFSv4.1] Shepler、S.、アイスラー、M.、およびD. Noveck、 "NFSv4のマイナーバージョン1"、進歩、2008年9月の作業。

[PAI+00] V. S. Pai, P. Druschel, W. Zwaenepoel, "IO-Lite: a unified I/O buffering and caching system", ACM Trans. Computer Systems, 18(1):37-66, Feb. 2000.

[PAI + 00] V. S.パイ、P. Druschel、W. Zwaenepoel、 "IO-Liteは：統一されたI / Oバッファリング及びキャッシングシステム"、ACMトランス。コンピュータシステム、18（1）：37から66まで、2000年2月。

[RDDP] RDDP Working Group charter, http://www.ietf.org/html.charters/rddpcharter.html.

[RDDP] RDDPワーキンググループのチャーター、http://www.ietf.org/html.charters/rddpcharter.html。

[RFC4297] Romanow, A., Mogul, J., Talpey, T., and S. Bailey, "Remote Direct Memory Access (RDMA) over IP Problem Statement", RFC 4297, December 2005.

[RFC4297] Romanow、A.、モーグル、J.、Talpey、T.、およびS.ベイリー、 "リモートダイレクトメモリアクセスIP問題文上（RDMA）"、RFC 4297、2005年12月。

[RFC1094] Sun Microsystems, "NFS: Network File System Protocol specification", RFC 1094, March 1989.

[RFC1094]サン・マイクロシステムズ、 "NFS：ネットワークシステムプロトコル仕様書ファイル"、RFC 1094、1989年3月を。

[RPCRDMA] Talpey, T. and B. Callaghan, "Remote Direct Memory Access Transport for Remote Procedure Call", Work in Progress, April 2008.

[RPCRDMA] Talpey、T.とB.キャラハン、「リモートプロシージャコールのためのリモートダイレクトメモリアクセス交通」、進歩、2008年4月の作業。

[SHI+03] P. Shivam, J. Chase, "On the Elusive Benefits of Protocol Offload", Proceedings of ACM SIGCOMM Summer 2003 NICELI Workshop, also available from http://issg.cs.duke.edu/publications/niceli03.pdf.

[SHI + 03] P. Shivam、J.チェイス、 "プロトコルオフロードのとらえどころのない利点について"、http://issg.cs.duke.edu/publications/niceli03からも入手できるACM SIGCOMM 2003年夏NICELIワークショップの議事録、 .PDF。

[SKE+01] K.-A. Skevik, T. Plagemann, V. Goebel, P. Halvorsen, "Evaluation of a Zero-Copy Protocol Implementation", in Proceedings of the 27th Euromicro Conference - Multimedia and Telecommunications Track (MTT'2001), Warsaw, Poland, September 2001.

[SKE + 01] K.-A.マルチメディアと通信トラック（MTT'2001）、ワルシャワ、ポーランド、2001年9月 - 27日Euromicro会議の議事録でSkevik、T. Plagemann、V.ゲーベル、P. Halvorsenの、「ゼロコピープロトコル実装の評価」、。

Authors' Addresses

著者のアドレス

Tom Talpey 170 Whitman St. Stow, MA 01775 USA

トムTalpey 170ホイットマンセントストウ、MA 01775 USA

Phone: +1 978 821-8577 EMail: tmtalpey@gmail.com

電話：+1 978 821-8577 Eメール：tmtalpey@gmail.com

Chet Juszczak P.O. Box 1467 Merrimack, NH 03054

チェットJuszczakの私書箱ボックス1467メリマック、NH 03054

Phone: +1 603 253-6602 EMail: chetnh@earthlink.net

電話：+1 603 253-6602 Eメール：chetnh@earthlink.net