[要約] 要約： RFC 5532は、NFSにおけるRDMAの問題を説明し、解決策を提案するものです。目的： このRFCの目的は、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
ネットワークファイルシステム（NFS）リモートダイレクトメモリアクセス（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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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
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）と呼ばれる処理アーキテクチャのクラスで使用されるいくつかのリモートファイルアクセスプロトコルの1つです。
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の下で採用された外部データ表現[RFC4506]およびリモートプロシージャコール（RPC）[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オーバーヘッドの問題に対する一般的な解決策です。実質的な研究がこれに取り組んでおり、アプローチの有効性を裏付けています。これの概要は、「IP問題ステートメント上のリモートダイレクトメモリアクセス（RDMA）」[RFC4297]です。
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対応NICS（RNICS）は、基礎となるプロトコル層（TCPなど）もオフロードし、NAS処理によるCPUオーバーヘッドをさらに削減します。
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.
コピーに関連する高コストは、主に大規模なシステムの問題です...オーバーヘッドをコピーすることで悪影響を受ける高帯域幅フィード、通常はマルチプロセッサとクラスターがあります。このようなマシンの例には、すべての品種のサーバーが含まれます。データベースサーバー、ストレージサーバー、トランザクション処理用のアプリケーションサーバー、eコマース、コンテンツ配信、ビデオ配信、バックアップ、データマイニングと意思決定サポート、科学的コンピューティング。
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.
このようなサーバーは、ほぼ排他的に多くの同時セッション（輸送接続）を使用しており、集計では1つ以上の通信を担当しています。それにもかかわらず、特定の負荷のオーバーヘッドをコピーするコストは、少数のセッションであれ多くのセッションであろうと同じです。
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スタックに渡す必要がある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.
コピーは、ユーザーアドレススペースとの間でデータを交換するNFS実装、カーネルバッファーキャッシュ内、外部データ表現（XDR）のマーシャリングとマーシャーショール、およびネットワークスタックとネットワークドライバー内で遭遇する可能性があります。単一の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が提供する直接メモリアドレス指定は、ネットワークリソースに関する多くの競合源を回避します。
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.
データのコピーは、システムバスの帯域幅とCPU時間を消費し、アプリケーションで利用可能なシステム容量を削減します[RFC4297]。これまで、NFSでゼロコピーを達成するには、洗練されたバージョン固有の「ヘッダークラッキング」ハードウェアおよび/または広範なプラットフォーム固有の仮想メモリマッピングトリックが必要です。このようなアプローチは、複合動作の存在と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 Gbits/sイーサネットなどの高速ネットワークファブリックに挑戦しています。TCPなどの生ネットワークI/Oさえも実行することは、今日のハードウェアでこのような速度で問題です。問題は本質的に基本的であり、IETFがRDMA [RFC4297]を探索するようになっています。
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] [DCK03] [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ファイルシステムを介して対話できるようにします。
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データストリームは、各タイプのトランスポートで異なる方法で伝達されます。UDPでは、RPCメッセージはデータグラム内にカプセル化されますが、TCPバイトストリームでは、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 |
+--------------------------------+---------------------------+
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 バイトごとのコスト - チェックサムやデータコピーなどのデータに触れるデータに触れます。今日のネットワークインターフェイスハードウェアは、一般にチェックサムをオフロードします。これにより、他の主要な路上路のデータコピーが残ります。
o per-packet costs - interrupts and lower-layer processing (LLP). Today's network interface hardware also commonly coalesce interrupts to reduce per-packet costs.
o パケットごとのコスト - 中断と低層処理（LLP）。今日のネットワークインターフェイスハードウェアは、一般に、パケットごとのコストを削減するために中断を合体します。
o per-message (request or response) costs - LLP and ULP processing.
o メッセージごと（リクエストまたは応答）コスト-LLPおよびULP処理。
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.
コピーがコピーごとに2回バスを渡ると、ネットワークの帯域幅がCPUやメモリ帯域幅と比較して大きい場合は、ネットワーク処理のオーバーヘッドが高くなります。一般に、今日の最終システムでは、効果は1 gbit/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 [RFC4297].
よくある質問は、CPU処理能力の増加がネットワークI/Oの高い処理コストの問題を軽減するかどうかです。答えはノーです、問題がメモリの帯域幅です。CPUがメモリを待つのにほとんどの時間を費やしている場合、より速いCPUは助けにはなりません[RFC4297]。
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）テクノロジーは、TCP/IPプロトコル処理をNICに移動することにより、CPUをオフロードすることを目的としています。ただし、つま先テクノロジー自体は、上層層プロトコル内の必要なデータコピーを避けるために何もしません。[MOG03]は、パケットあたりのコストを削減する際に、つま先が果たすことができる役割の説明を提供します。今日のネットワークインターフェイスハードウェアによって一般的に提供されるオフロードを超えて、つま先だけで（RDMAなし）プロトコルヘッダー処理に役立ちますが、これはトータルプロトコル処理オーバーヘッドの少数派のコンポーネントであることが示されています。[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やディスクI/O [BRU99] [CHU96]などのシステム処理の他の側面と相互作用することが示されています。ページの再マッピング[CHU96]に基づくゼロコピーの最適化は、マシンアーキテクチャに依存する可能性があり、マルチプロセッサアーキテクチャにはスケーラブルではありません。ゼロコピー運動メカニズムのパフォーマンスを最適化するには、正しいバッファーアライメントとサイジングが一緒に必要です[Ske 01]。上記のNFSメッセージレイアウトは、データからのヘッダーの分割を容易にしたり、正しいデータバッファーアライメントを提供することを容易にしません。
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]は、問題を説明するのに役立つ一連の「法律」パラメーターを提示します。つま先の場合、コピーコストは、アプリケーション処理「A」の一部として表示できます。アプリケーション処理により、法律「ガンマ」が増加します。これは、つま先の利益が減少するために論文で示されます。
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％の場合、ガンマは80/20または4です。つま先の最大利益は1/ガンマ、または25％のみです。
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.
RDMA（つま先が埋め込まれている）と同じ例の場合、「オーバーヘッド」（o）オフロードまたは排除は50％（20％30％）です。したがって、RDMAの場合、ガンマは50/50または1であり、逆数は1（100％）の潜在的な利点を与えます。
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なしで完全なネットワーク帯域幅を駆動するのに十分なほど強力である場合でも、RDMAが2つの係数でスループットを改善できることを示しています。また、ネットワーク帯域幅がムーアの法則よりも速く成長する場合、スピードアップが高くなる可能性があることも示すことができますが、より高い利点は狭い範囲のアプリケーションに適用されます。
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-Over-RDMAプロトタイプと従来のネットワークベースのNFS処理を直接比較するパフォーマンス測定は、[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.
これらの結果では、従来のネットワークベースのスループットは、すべての転送でクライアントのCPUが100％で飽和していることにより、厳しく制限されていました。読み取りスループットは60 mバイト/s以下に達しました。
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%
However, over RDMA, throughput rose to the theoretical maximum throughput of the platform, while saturating the single-CPU system only at maximum throughput.
ただし、RDMAでは、スループットがプラットフォームの理論的な最大スループットに上昇し、最大スループットでのみ単一CPUシステムを飽和させました。
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%
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部分内のパケットごとのセットアップコストの相対的な増加を反映している可能性があります。
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プロトコルのパフォーマンスを向上させる機会を提供します。データチャンクは、上記のクライアントとサーバーメモリアドレスの間に「直接」コピーできます（各メモリバスで1回の発生を使用）、制御情報は「インライン」に渡すことができます。[RPCRDMA]は、このようなプロトコルについて説明しています。
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 versioning is a conservative and cautious approach to current and future problems and shortcomings.
NFSバージョン4は、上記の必要なパフォーマンスの拡張と改善されたセマンティクスを追加するための優れたベースです。NFSバージョン4で定義されているマイナーバージョンサポートは、インストールされたベース[NFSV4.1]を破壊することなくプロトコルの改善をサポートするように設計されました。マイナーバージョン化によるプロトコルの進化的改善は、現在および将来の問題と欠点に対する保守的で慎重なアプローチです。
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プロトコルに既に存在する価値に基づいて構築することができ、ネットワーキングテクノロジーの適用から生じた新しい要件に対処します。
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-over-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.
「チャネルバインディング」コンセプト[RFC5056]と「IPSECチャネル接続ラッチ」[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]の要件に適合する必要があります。
The authors wish to thank Jeff Chase who provided many useful suggestions.
著者は、多くの有用な提案を提供してくれたジェフチェイスに感謝したいと考えています。
[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.、Callaghan、B.、Robinson、D.、Thurlow、R.、Beame、C.、Eisler、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] Eisler、M.、ed。、「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] Callaghan、B.、Pawlowski、B。、およびP. Staubach、「NFSバージョン3プロトコル仕様」、RFC 1813、1995年6月。
[RFC5403] Eisler, M., "RPCSEC_GSS Version 2", RFC 5403, February 2009.
[RFC5403] Eisler、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] Pinkerton、J。およびE. Deleganes、「ダイレクトデータ配置プロトコル（DDP） /リモートダイレクトメモリアクセスプロトコル（RDMAP）セキュリティ」、RFC 5042、2007年10月。
[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.
[Bru99] J. Brustoloni、「ネットワークおよびファイルI/Oでのコピー回避の相互操作」、Proc。Infocom '99、ページ534-542、ニューヨーク、ニューヨーク、1999年3月、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. Callaghan、T。Lingutla-Raj、A。Chiu、P。Staubach、O。Asad、「NFS Over RDMA」、ACM Sigcomm Summer 2003 Niceli Workshopの議事録。
[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. Chase、A。J。Gallatin、K。G。Yocum、「高速TCPのエンドシステムの最適化」、IEEE Communications、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] J. S. Chase、D。C. Anderson、A。J. Gallatin、A。R. Lebeck、K。G. Yocum、「Trapeze with Trapeze with Trapeze」、1999年8月、1999年8月。
[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.Chu、「SolarisのゼロコピーTCP」、Proc。1996年1月、カリフォルニア州サンディエゴのUsenix 1996年次技術会議。
[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] M. Debergalis、P。Corbett、S。Kleiman、A。Lent、D。Noveck、T。Talpey、M。Wittle、「The Direct Access File System」、ファイルとストレージに関する第2回Usenix会議の議事録Technologies（Fast '03）、カリフォルニア州サンフランシスコ、3月31日 - 2003年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]藤井プライムソフトウェアテクノロジー、「Clanを使用したDAFS/VIカーネルの実装でDAFSパフォーマンスを満たす」、http：//www.pst.fujitsu.com/english/dafsdemo/index.html、2001年から入手できます。
[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]富士通プライムソフトウェアテクノロジー、「LinuxでのNFSへのViaの適応」、http：//www.pst.fujitsu.com/english/nfs/index.html、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. Gallatin、J。Chase、K。Yocum、「Trapeze/IP：TCP/IP at Near-Gigabit Speeds」、1999 Usenix Technical Conference（Freenix Track）、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.
[KM02] K. Magoutis、「FreeBSD用の直接アクセスファイルシステム（DAFS）カーネルサーバーの設計と実装」、Usenix BSDCON 2002会議の議事録、カリフォルニア州サンフランシスコ、2002年2月11〜14日。
[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。Fedorova、M。Seltzer、J。Chase、D。Gallatin、R。Kisley、R。Wickremesinghe、E。Gabber、「直接アクセスファイルシステムの構造とパフォーマンス（DAFS）」、2002年のUSENIX年次技術会議の議事録、カリフォルニア州モントレー、2002年6月9〜14日。
[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. Mogul、「TCPオフロードは、その時が来た愚かなアイデアです」、9番目のオペレーティングシステム（Hotos IX）、Lihue、HI、2003年5月。
[NFSv4.1] Shepler, S., Eisler, M., and D. Noveck, "NFSv4 Minor Version 1", Work in Progress, September 2008.
[NFSV4.1] Shepler、S.、Eisler、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. Pai、P。Druschel、W。Zwaenepoel、「io-lite：統一されたI/Oバッファリングおよびキャッシュシステム」、ACM Trans。コンピューターシステム、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.、Mogul、J.、Talpey、T。、およびS. Bailey、「IP問題ステートメント上のリモートダイレクトメモリアクセス（RDMA）」、RFC 4297、2005年12月。
[RFC1094] Sun Microsystems, "NFS: Network File System Protocol specification", RFC 1094, March 1989.
[RFC1094] Sun Microsystems、「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。and B. Callaghan、「リモートプロシージャコールのリモートダイレクトメモリアクセストランスポート」、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。Chase、「プロトコルオフロードのとらえどころのない利点について」、ACM Sigcomm 2003 Summer Niceli Workshopの議事録、http：//issg.cs.duke.edu/publications/niceli03から入手できます。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。Skevik、T。Plagemann、V。Goebel、P。Halvorsen、「ゼロコピープロトコル実装の評価」、第27回ユーロミクロ会議の議事録 - マルチメディアおよびテレコミュニケーショントラック（MTT'2001）、2001年9月、ポーランド、ワルーソー
Authors' Addresses
著者のアドレス
Tom Talpey 170 Whitman St. Stow, MA 01775 USA
Tom Talpey 170ホイットマンセントストウ、マサチューセッツ州01775 USA
Phone: +1 978 821-8577
EMail: tmtalpey@gmail.com
Chet Juszczak P.O. Box 1467 Merrimack, NH 03054
Chet Juszczak P.O.Box 1467 Merrimack、NH 03054
Phone: +1 603 253-6602
EMail: chetnh@earthlink.net