From rddp-bounces@ietf.org Fri Oct 1 01:17:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07337 for ; Fri, 1 Oct 2004 01:17:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDFvd-0005Vz-3e for rddp-web-archive@ietf.org; Fri, 01 Oct 2004 01:26:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDFYZ-000797-Qi; Fri, 01 Oct 2004 01:02:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDFPv-0004T2-7F for rddp@megatron.ietf.org; Fri, 01 Oct 2004 00:53:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06002 for ; Fri, 1 Oct 2004 00:53:11 -0400 (EDT) Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDFYG-0004rl-4m for rddp@ietf.org; Fri, 01 Oct 2004 01:01:55 -0400 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel6.hp.com (Postfix) with ESMTP id 7D893166A for ; Fri, 1 Oct 2004 00:53:07 -0400 (EDT) Received: from india.hp.com (kanha.india.hp.com [15.42.231.94]) by iconsrv6.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id KAA25099 for ; Fri, 1 Oct 2004 10:23:27 +0530 (IST) Message-ID: <415CE412.4040805@india.hp.com> Date: Fri, 01 Oct 2004 10:28:58 +0530 From: Mohan Parthasarathy User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.3) Gecko/20030321 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rddp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [rddp] Rgerading RDMA/SDP and traditional socket apps X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Hi, I am new to RDMA and would appreciate if my questions are viewed with tolerance. I believe existing socket apps doing a send and reusing the buffer will not work with RDMA since the send might not have completed. Isn't it possible to copy the user buffer to another in the SDP library, to let the user app reuse the buffer ? I guess it might lead to increase in memory usage, but it will be only for legacy apps not using the RDMA capabilities, and will probbaly be no different from today's situation where often the user buffer gets copied to a kernel buffer. Also, are there any new socket APIs in SDP or variations in the current socket calls to distinguish if the caller can handle running over RDMA ? Another way to phrase that is if SDP will be aware of legacy apps versus new ones. Regards, Mohan _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailman-bounces@ietf.org Fri Oct 1 06:33:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15281 for ; Fri, 1 Oct 2004 06:33:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDKrm-0003tA-7h for rddp-web-archive@ietf.org; Fri, 01 Oct 2004 06:42:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJgM-00029i-Gj for rddp-web-archive@ietf.org; Fri, 01 Oct 2004 05:26:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: rddp-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:11:12 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for rddp-web-archive@ietf.org: List Password // URL ---- -------- rddp@ietf.org jOsP https://www1.ietf.org/mailman/options/rddp/rddp-web-archive%40ietf.org From rddp-bounces@ietf.org Fri Oct 1 11:01:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07119 for ; Fri, 1 Oct 2004 11:01:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDP3M-0000Zu-GL for rddp-web-archive@ietf.org; Fri, 01 Oct 2004 11:10:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDKKB-0003w6-KR; Fri, 01 Oct 2004 06:07:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJKq-0002uH-9p for rddp@megatron.ietf.org; Fri, 01 Oct 2004 05:04:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08162 for ; Fri, 1 Oct 2004 05:04:14 -0400 (EDT) Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDJTD-000246-Hj for rddp@ietf.org; Fri, 01 Oct 2004 05:12:58 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id 5555111E0EB; Fri, 1 Oct 2004 05:04:10 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29954-07; Fri, 1 Oct 2004 05:04:09 -0400 (EDT) Received: from [192.168.1.2] (bzq-198-76.red.bezeqint.net [212.179.198.76]) by host52a.simplicato.com (Postfix) with ESMTP id A92C411E0E0; Fri, 1 Oct 2004 05:04:07 -0400 (EDT) In-Reply-To: <415CE412.4040805@india.hp.com> References: <415CE412.4040805@india.hp.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Caitlin Bestler Subject: Re: [rddp] Rgerading RDMA/SDP and traditional socket apps Date: Fri, 1 Oct 2004 11:04:07 +0200 To: Mohan Parthasarathy X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at simplicato.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: rddp@ietf.org X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit On Oct 1, 2004, at 7:58 AM, Mohan Parthasarathy wrote: > Hi, > > I am new to RDMA and would appreciate if my questions are viewed > with tolerance. > I believe existing socket apps doing a send and reusing the buffer > will > not work with RDMA since the send might not have completed. > Isn't it possible to copy the user buffer to another in the SDP > library, > to let the user app reuse the buffer ? I guess it might lead to > increase > in memory usage, but it will be only for legacy apps not using the > RDMA capabilities, and will probbaly be no different from today's > situation where often the user buffer gets copied to a kernel buffer. > Also, are there any new socket APIs in SDP or variations in the > current > socket calls to distinguish if the caller can handle running over > RDMA ? > Another way to phrase that is if SDP will be aware of legacy apps > versus new ones. > > Regards, > Mohan > > The purpose of SDP is to identify when zero-copy transfers can be done, directly using either the ULP source or destination buffer directly, without requiring a fundamental change in the how the application uses the network. Without SDP a stack can only identify zero-copy opportunities locally, without collaborating with the peer's stack. However, an optimized local stack can identify many zero-copy opportunities, and when it does it is without the overhead and latency of additional wire traffic. The tradeoff between local-stack-only optimization and SDP-enabled optimization is complex and dependent on the application and deployment environment. Obviously an RDMA aware application that explicitly posts receive operations and explicitly exports STags to advertise buffers is going to avoid intermediate copying *all* of the time, something that SDP can only hope to approach. Both an optimized local stack, such as a TOE, and SDP are valuable tools to achieve partial zero-copy without requiring program redesign. Achieving the full potential of RDMA requires designing the Upper Layer Protocol and its implementation on both peers to be RDMA aware. The SDP specification is an excellent source on when and how SDP identifies zero-copy opportunities. The Applicability Statement discusses the impact of RDMA on application design. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Fri Oct 1 13:09:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25956 for ; Fri, 1 Oct 2004 13:09:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDR2Z-0003wZ-H4 for rddp-web-archive@ietf.org; Fri, 01 Oct 2004 13:17:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQ9J-00073x-7Z; Fri, 01 Oct 2004 12:20:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDO93-0008Ag-7f for rddp@megatron.ietf.org; Fri, 01 Oct 2004 10:12:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02590 for ; Fri, 1 Oct 2004 10:12:23 -0400 (EDT) Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDOHV-00085r-V2 for rddp@ietf.org; Fri, 01 Oct 2004 10:21:10 -0400 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel12.hp.com (Postfix) with ESMTP id D7B9A409447 for ; Fri, 1 Oct 2004 07:12:19 -0700 (PDT) Received: from MK73191c.cup.hp.com (mk731916.cup.hp.com [15.8.80.134]) by esmail.cup.hp.com (8.9.3 (PHNE_29774)/8.8.6) with ESMTP id HAA15488; Fri, 1 Oct 2004 07:10:50 -0700 (PDT) Message-Id: <6.1.2.0.2.20041001070726.01e92b18@esmail.cup.hp.com> X-Sender: krause@esmail.cup.hp.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 01 Oct 2004 07:12:11 -0700 To: Mohan Parthasarathy , rddp@ietf.org From: Michael Krause Subject: Re: [rddp] Rgerading RDMA/SDP and traditional socket apps In-Reply-To: <415CE412.4040805@india.hp.com> References: <415CE412.4040805@india.hp.com> Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1397941273==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f --===============1397941273== Content-Type: multipart/alternative; boundary="=====================_2959866==.ALT" --=====================_2959866==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 09:58 PM 9/30/2004, Mohan Parthasarathy wrote: >Hi, > > I am new to RDMA and would appreciate if my questions are viewed > with tolerance. > I believe existing socket apps doing a send and reusing the buffer will > not work with RDMA since the send might not have completed. > Isn't it possible to copy the user buffer to another in the SDP library, > to let the user app reuse the buffer ? I guess it might lead to increase > in memory usage, but it will be only for legacy apps not using the > RDMA capabilities, and will probbaly be no different from today's > situation where often the user buffer gets copied to a kernel buffer. > Also, are there any new socket APIs in SDP or variations in the current > socket calls to distinguish if the caller can handle running over RDMA ? > Another way to phrase that is if SDP will be aware of legacy apps > versus new ones. If the sockets call returns, then the ownership of the associated buffer is also returned. SDP does not change this. Therefore, the application can reuse the buffer. Today's network stacks do not guarantee that a buffer has been sent when a sockets call returns. All that is guaranteed is that the underlying implementation will attempt to deliver the buffer to the remote. The same applies to RDMA implementations. The implementation will attempt to deliver the buffer. If the buffer is returned, then either it was successfully sent or there is a local copy within the RNIC or a side buffer (e.g. a local copy to host memory) that will be used to send the data. The application does not need to worry about this. SDP does not have to worry about this either. This is the RI / RNIC's responsibility. A good explanation can be found in the verbs draft specification which has been posted to this reflector / website. Mike --=====================_2959866==.ALT Content-Type: text/html; charset="us-ascii" At 09:58 PM 9/30/2004, Mohan Parthasarathy wrote:
Hi,

 I am new to RDMA and would appreciate if my questions are viewed
 with tolerance.
 I believe existing socket apps doing a send and reusing the buffer will
 not work with RDMA since the send might not have completed.
 Isn't it possible to copy the user buffer to another in the SDP library,
 to let the user app reuse the buffer ? I guess it might lead to increase
 in memory usage, but it will be only for legacy apps not using the
 RDMA capabilities, and will probbaly be no different from today's
 situation where often the user buffer gets copied to a kernel buffer.
 Also, are there any new socket APIs in SDP or variations in the current
 socket calls to distinguish if the caller can handle running over RDMA ?
 Another way to phrase that is if SDP will be aware of legacy apps
 versus new ones.

If the sockets call returns, then the ownership of the associated buffer is also returned.  SDP does not change this.  Therefore, the application can reuse the buffer.  Today's network stacks do not guarantee that a buffer has been sent when a sockets call returns.  All that is guaranteed is that the underlying implementation will attempt to deliver the buffer to the remote.  The same applies to RDMA implementations.  The implementation will attempt to deliver the buffer.  If the buffer is returned, then either it was successfully sent or there is a local copy within the RNIC or a side buffer (e.g. a local copy to host memory) that will be used to send the data.  The application does not need to worry about this.  SDP does not have to worry about this either.  This is the RI / RNIC's responsibility.  A good explanation can be found in the verbs draft specification which has been posted to this reflector / website.

Mike --=====================_2959866==.ALT-- --===============1397941273== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============1397941273==-- From rddp-bounces@ietf.org Fri Oct 1 19:16:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09597 for ; Fri, 1 Oct 2004 19:16:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDWmN-00007e-U7 for rddp-web-archive@ietf.org; Fri, 01 Oct 2004 19:25:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDWOf-0004g3-UG; Fri, 01 Oct 2004 19:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDWBq-0001I1-Ao for rddp@megatron.ietf.org; Fri, 01 Oct 2004 18:47:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04724 for ; Fri, 1 Oct 2004 18:47:47 -0400 (EDT) Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDWKD-00059u-An for rddp@ietf.org; Fri, 01 Oct 2004 18:56:39 -0400 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id AE88239000E6; Fri, 01 Oct 2004 18:47:36 -0400 From: "Barry Reinhold" To: "RDDP" Date: Fri, 1 Oct 2004 18:47:28 -0400 Message-ID: <001601c4a808$a4043380$b7d0fea9@i8600> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: iwarp@iol.unh.edu Subject: [rddp] startup behavior of MPA X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit When an MPA implementation sends a startup request frame and receives a FPDU back, it is not allowed to interpret/process the FPDU. However, the spec does not appear to address the condition after reception of the FPDU. One can consider this to be an error and have the connection terminated. However, it is not clear that this has to be the situation. The question is, is it a "MUST" that the connection be terminated on reception of a FPDU before a startup reply frame? Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Fri Oct 1 20:50:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13821 for ; Fri, 1 Oct 2004 20:50:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDYFB-0002GN-7S for rddp-web-archive@ietf.org; Fri, 01 Oct 2004 20:59:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDXvp-0006Gz-FJ; Fri, 01 Oct 2004 20:39:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDXsu-0002ig-JT for rddp@megatron.ietf.org; Fri, 01 Oct 2004 20:36:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13315 for ; Fri, 1 Oct 2004 20:36:21 -0400 (EDT) Received: from magic.adaptec.com ([216.52.22.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDY1S-0001xZ-Sy for rddp@ietf.org; Fri, 01 Oct 2004 20:45:15 -0400 Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id i920ZqW18119; Fri, 1 Oct 2004 17:35:52 -0700 Received: from aime2k02.adaptec.com (aime2k02.adaptec.com [10.25.8.42]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id i920Zqm25330; Fri, 1 Oct 2004 17:35:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Oct 2004 17:35:51 -0700 Message-ID: Thread-Topic: startup behavior of MPA Thread-Index: AcSoCLmgMoVnv2m3SSiTh9FbU7o/CgADliPw From: "Carrier, John" To: "Barry Reinhold" , "RDDP" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: iwarp@iol.unh.edu Subject: [rddp] RE: startup behavior of MPA X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable The sender of the request has no way of interpreting the FPDU as an FPDU = because it is still in TCP streaming mode until after it has received = the MPA Reply frame. Since the requester is expecting the MPA Reply = frame, it will interpret the FPDU as if it was an MPA reply, determine = that the reply is invalid, and then terminate the connection. =20 --jc=20 > -----Original Message----- > From: owner-iwarp@io.iol.unh.edu [mailto:owner-iwarp@io.iol.unh.edu]On > Behalf Of Barry Reinhold > Sent: Friday, October 01, 2004 3:47 PM > To: RDDP > Cc: iwarp@iol.unh.edu > Subject: startup behavior of MPA >=20 >=20 > When an MPA implementation sends a startup request frame and=20 > receives a > FPDU back, it is not allowed to interpret/process the FPDU.=20 > However, the > spec does not appear to address the condition after reception of the > FPDU. One can consider this to be an error and have the connection > terminated. However, it is not clear that this has to be the=20 > situation. >=20 > The question is, is it a "MUST" that the connection be terminated on > reception of a FPDU before a startup reply frame? >=20 > Barry Reinhold > Lamprey Networks > bbr@lampreynetworks.com > (603) 868-8411 > =20 >=20 >=20 >=20 >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Sat Oct 2 00:12:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06888 for ; Sat, 2 Oct 2004 00:12:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDbOV-0007DZ-0I for rddp-web-archive@ietf.org; Sat, 02 Oct 2004 00:21:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDbA6-0001N0-Sq; Sat, 02 Oct 2004 00:06:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDb3d-0004gn-53 for rddp@megatron.ietf.org; Fri, 01 Oct 2004 23:59:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04507 for ; Fri, 1 Oct 2004 23:59:38 -0400 (EDT) Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDbCD-0006h3-T8 for rddp@ietf.org; Sat, 02 Oct 2004 00:08:34 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id BCA5011E169; Fri, 1 Oct 2004 23:59:33 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93438-05; Fri, 1 Oct 2004 23:59:32 -0400 (EDT) Received: from [192.168.1.2] (bzq-198-76.red.bezeqint.net [212.179.198.76]) by host52a.simplicato.com (Postfix) with ESMTP id 1C3B411E13C; Fri, 1 Oct 2004 23:59:30 -0400 (EDT) In-Reply-To: <001601c4a808$a4043380$b7d0fea9@i8600> References: <001601c4a808$a4043380$b7d0fea9@i8600> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <78E4BF9E-1427-11D9-B24D-000393814604@asomi.com> Content-Transfer-Encoding: 7bit From: Caitlin Bestler Subject: Re: [rddp] startup behavior of MPA Date: Sat, 2 Oct 2004 05:59:34 +0200 To: "Barry Reinhold" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at simplicato.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: iwarp@iol.unh.edu, RDDP X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit On Oct 2, 2004, at 1:47 AM, Barry Reinhold wrote: > When an MPA implementation sends a startup request frame and receives a > FPDU back, it is not allowed to interpret/process the FPDU. However, > the > spec does not appear to address the condition after reception of the > FPDU. One can consider this to be an error and have the connection > terminated. However, it is not clear that this has to be the situation. > > The question is, is it a "MUST" that the connection be terminated on > reception of a FPDU before a startup reply frame? > > The respondent side MUST NOT send the first FPDU until after it has received the first FPDU itself, which the initiating side MUST NOT send until after it receives the startup reply. So reception of an FPDU before a startup reply frame indicates that the other side has violated a MUST. As with any other protocol violation by the peer it MAY choose to terminate the connection, and SHOULD do so if the violation could in any way be used to compromise security. But it is not obligated to do so. In particular, it does not have to take extra steps to insure that it notices this condition. An MPA implementation that processes TCP segments in order, for example, would not notice that the FPDU had been received before the startup reply frame. An MPA implementation that processed TCP segments as they arrived would not know whether the TCP segment was part of the MPA REP message or part of an FPDU, and therefore could easily be incapable of submitting it to MPA processing. That is why the peer was required not to send it. Also remember that this is an MPA requirement, not an RDDP requirement. There is no restriction on first transmit under the SCTP mapping. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Oct 4 00:40:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19536 for ; Sun, 3 Oct 2004 23:50:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEK0h-0005FH-DZ for rddp-web-archive@ietf.org; Sun, 03 Oct 2004 23:59:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJjf-0004vx-RR; Sun, 03 Oct 2004 23:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJiM-0003zR-UR for rddp@megatron.ietf.org; Sun, 03 Oct 2004 23:40:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11705 for ; Sun, 3 Oct 2004 23:40:36 -0400 (EDT) Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEJD5-0006Ra-QB for rddp@ietf.org; Sun, 03 Oct 2004 23:08:24 -0400 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel8.hp.com (Postfix) with ESMTP id BDD8F8665 for ; Sun, 3 Oct 2004 22:59:00 -0400 (EDT) Received: from india.hp.com (kanha.india.hp.com [15.42.231.94]) by iconsrv6.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id IAA23252; Mon, 4 Oct 2004 08:29:17 +0530 (IST) Message-ID: <4160BDD4.9040804@india.hp.com> Date: Mon, 04 Oct 2004 08:34:52 +0530 From: Mohan Parthasarathy User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.3) Gecko/20030321 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Krause Subject: Re: [rddp] Rgerading RDMA/SDP and traditional socket apps References: <415CE412.4040805@india.hp.com> <6.1.2.0.2.20041001070726.01e92b18@esmail.cup.hp.com> In-Reply-To: <6.1.2.0.2.20041001070726.01e92b18@esmail.cup.hp.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: rddp@ietf.org X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0446037618==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 This is a multi-part message in MIME format. --===============0446037618== Content-Type: multipart/alternative; boundary="------------090909050208060702030003" This is a multi-part message in MIME format. --------------090909050208060702030003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Mike/Caitlin, Thanks for the answers. So, what I understand is that my assumption that existing socket apps might not have ownership of the buffer when the send completes, was wrong. But, doesn't this mean that send calls will take more time to complete, if the RNIC has to DMA the buffers before control to the buffer is returned to the caller. Are there any potential performance issues here for existing synchronous sockets ? Regards, Mohan Michael Krause wrote: > At 09:58 PM 9/30/2004, Mohan Parthasarathy wrote: > >> Hi, >> >> I am new to RDMA and would appreciate if my questions are viewed >> with tolerance. >> I believe existing socket apps doing a send and reusing the buffer will >> not work with RDMA since the send might not have completed. >> Isn't it possible to copy the user buffer to another in the SDP library, >> to let the user app reuse the buffer ? I guess it might lead to increase >> in memory usage, but it will be only for legacy apps not using the >> RDMA capabilities, and will probbaly be no different from today's >> situation where often the user buffer gets copied to a kernel buffer. >> Also, are there any new socket APIs in SDP or variations in the current >> socket calls to distinguish if the caller can handle running over RDMA ? >> Another way to phrase that is if SDP will be aware of legacy apps >> versus new ones. > > > If the sockets call returns, then the ownership of the associated > buffer is also returned. SDP does not change this. Therefore, the > application can reuse the buffer. Today's network stacks do not > guarantee that a buffer has been sent when a sockets call returns. > All that is guaranteed is that the underlying implementation will > attempt to deliver the buffer to the remote. The same applies to RDMA > implementations. The implementation will attempt to deliver the > buffer. If the buffer is returned, then either it was successfully > sent or there is a local copy within the RNIC or a side buffer (e.g. a > local copy to host memory) that will be used to send the data. The > application does not need to worry about this. SDP does not have to > worry about this either. This is the RI / RNIC's responsibility. A > good explanation can be found in the verbs draft specification which > has been posted to this reflector / website. > > Mike --------------090909050208060702030003 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Mike/Caitlin,

  Thanks for the answers. So, what I understand is that my assumption
  that existing socket apps might not have ownership of the buffer when
  the send completes, was wrong.
  But, doesn't this mean that send calls will take more time to complete,
  if the RNIC has to DMA the buffers before control to the buffer is
  returned to the caller. Are there any potential performance issues here
  for existing synchronous sockets ?

Regards,
Mohan

Michael Krause wrote:
At 09:58 PM 9/30/2004, Mohan Parthasarathy wrote:
Hi,

 I am new to RDMA and would appreciate if my questions are viewed
 with tolerance.
 I believe existing socket apps doing a send and reusing the buffer will
 not work with RDMA since the send might not have completed.
 Isn't it possible to copy the user buffer to another in the SDP library,
 to let the user app reuse the buffer ? I guess it might lead to increase
 in memory usage, but it will be only for legacy apps not using the
 RDMA capabilities, and will probbaly be no different from today's
 situation where often the user buffer gets copied to a kernel buffer.
 Also, are there any new socket APIs in SDP or variations in the current
 socket calls to distinguish if the caller can handle running over RDMA ?
 Another way to phrase that is if SDP will be aware of legacy apps
 versus new ones.

If the sockets call returns, then the ownership of the associated buffer is also returned.  SDP does not change this.  Therefore, the application can reuse the buffer.  Today's network stacks do not guarantee that a buffer has been sent when a sockets call returns.  All that is guaranteed is that the underlying implementation will attempt to deliver the buffer to the remote.  The same applies to RDMA implementations.  The implementation will attempt to deliver the buffer.  If the buffer is returned, then either it was successfully sent or there is a local copy within the RNIC or a side buffer (e.g. a local copy to host memory) that will be used to send the data.  The application does not need to worry about this.  SDP does not have to worry about this either.  This is the RI / RNIC's responsibility.  A good explanation can be found in the verbs draft specification which has been posted to this reflector / website.

Mike


--------------090909050208060702030003-- --===============0446037618== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============0446037618==-- From rddp-bounces@ietf.org Mon Oct 4 01:01:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10060 for ; Mon, 4 Oct 2004 01:01:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEL7W-0000IN-7R for rddp-web-archive@ietf.org; Mon, 04 Oct 2004 01:10:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEKsI-0006ym-2B; Mon, 04 Oct 2004 00:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEKjq-0003ig-9w for rddp@megatron.ietf.org; Mon, 04 Oct 2004 00:46:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06456 for ; Mon, 4 Oct 2004 00:46:14 -0400 (EDT) Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEKsq-0007gE-B8 for rddp@ietf.org; Mon, 04 Oct 2004 00:55:36 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id D23E611E09C; Mon, 4 Oct 2004 00:46:07 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62449-08; Mon, 4 Oct 2004 00:46:07 -0400 (EDT) Received: from [192.168.1.2] (bzq-198-76.red.bezeqint.net [212.179.198.76]) by host52a.simplicato.com (Postfix) with ESMTP id 5511F11E09A; Mon, 4 Oct 2004 00:46:06 -0400 (EDT) In-Reply-To: <4160BDD4.9040804@india.hp.com> References: <415CE412.4040805@india.hp.com> <6.1.2.0.2.20041001070726.01e92b18@esmail.cup.hp.com> <4160BDD4.9040804@india.hp.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <5038F2D1-15C0-11D9-9A80-000393814604@asomi.com> Content-Transfer-Encoding: quoted-printable From: Caitlin Bestler Subject: Re: [rddp] Rgerading RDMA/SDP and traditional socket apps Date: Mon, 4 Oct 2004 06:46:10 +0200 To: RDDP X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at simplicato.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: Mohan Parthasarathy X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable On Oct 4, 2004, at 5:04 AM, Mohan Parthasarathy wrote: > Hi Mike/Caitlin, > > =A0 Thanks for the answers. So, what I understand is that my = assumption > =A0 that existing socket apps might not have ownership of the buffer=20= > when > =A0 the send completes, was wrong. > =A0 But, doesn't this mean that send calls will take more time to=20 > complete, > =A0 if the RNIC has to DMA the buffers before control to the buffer = is > =A0 returned to the caller. Are there any potential performance = issues=20 > here > =A0 for existing synchronous sockets ? > > Regards, > Mohan SDP defines multiple transfer procedures precisely to avoid this problem. SDP should be configured so that zero-copy transfers are only done when doing so will improve performance. For example, when the receive is posted long enough before the send for the data sink buffer to have been advertised the data source can RDMA Write to the final target buffer without any delay. SDP inherently involves more wire traffic, but depending on the timing of sends and receives this extra traffic may have no impact on latency. The benefits of direct placement should overcome any penalty for the wire traffic. But that penalty is there, which is why local-only optimizations that achieve direct placement without wire traffic might be more efficient, and why full adaptation to RDMA-aware application logic will almost always be more efficient. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Oct 4 08:28:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00161 for ; Mon, 4 Oct 2004 08:28:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CES5z-0006l2-PU for rddp-web-archive@ietf.org; Mon, 04 Oct 2004 08:37:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CERt1-0008B9-Fq; Mon, 04 Oct 2004 08:24:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CERjW-0006Rn-QM for rddp@megatron.ietf.org; Mon, 04 Oct 2004 08:14:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29245 for ; Mon, 4 Oct 2004 08:14:25 -0400 (EDT) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CERsb-0003x8-EU for rddp@ietf.org; Mon, 04 Oct 2004 08:23:49 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i94CDpfQ141774; Mon, 4 Oct 2004 12:13:51 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i94CDjOL104886; Mon, 4 Oct 2004 14:13:46 +0200 In-Reply-To: <5038F2D1-15C0-11D9-9A80-000393814604@asomi.com> Subject: Re: [rddp] Rgerading RDMA/SDP and traditional socket apps To: Caitlin Bestler X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: Vadim Makhervaks Date: Mon, 4 Oct 2004 14:13:37 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 04/10/2004 14:13:50 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Cc: rddp-bounces@ietf.org, Mohan Parthasarathy , RDDP X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Caitlin, I tend to agree with Mohan's observation. Preposted receive buffers all= ow to eliminate a need in buffer advertising, but it still involves delay.= I can see two options: option a) RNIC does not keep any intermediate buff= er, and then it needs to wait to Ack to arrive, before releasing consumer buffer, option b) RNIC keeps intermediate buffers, and then consumer buffer is released after it is copied to the intermediate buffer. In bo= th cases we have delay involved in blocking send operation, plus some sort= of hw/sw sync/coordination to report completion of operation and release a= buffer. Vadim |---------+----------------------------> | | Caitlin Bestler | | | | | | Sent by: | | | rddp-bounces@ietf| | | .org | | | | | | | | | 04/10/04 06:46 | |---------+----------------------------> >--------------------------------------------------------------------= -----------------------------------------------------------| | = | | To: RDDP = | | cc: Mohan Parthasarathy = | | Subject: Re: [rddp] Rgerading RDMA/SDP and traditional socke= t apps | >--------------------------------------------------------------------= -----------------------------------------------------------| On Oct 4, 2004, at 5:04 AM, Mohan Parthasarathy wrote: > Hi Mike/Caitlin, > > =A0 Thanks for the answers. So, what I understand is that my assumpt= ion > =A0 that existing socket apps might not have ownership of the buffer= > when > =A0 the send completes, was wrong. > =A0 But, doesn't this mean that send calls will take more time to > complete, > =A0 if the RNIC has to DMA the buffers before control to the buffer = is > =A0 returned to the caller. Are there any potential performance issu= es > here > =A0 for existing synchronous sockets ? > > Regards, > Mohan SDP defines multiple transfer procedures precisely to avoid this problem. SDP should be configured so that zero-copy transfers are only done when doing so will improve performance. For example, when the receive is posted long enough before the send for the data sink buffer to have been advertised the data source can RDMA Write to the final target buffer without any delay. SDP inherently involves more wire traffic, but depending on the timing of sends and receives this extra traffic may have no impact on latency. The benefits of direct placement should overcome any penalty for the wire traffic. But that penalty is there, which is why local-only optimizations that achieve direct placement without wire traffic might be more efficient, and why full adaptation to RDMA-aware application logic will almost always be more efficient. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp = _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Oct 4 09:50:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05685 for ; Mon, 4 Oct 2004 09:50:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CETNl-0004QO-6m for rddp-web-archive@ietf.org; Mon, 04 Oct 2004 10:00:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CETD8-00016Z-RT; Mon, 04 Oct 2004 09:49:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CETBe-0000bI-Ne for rddp@megatron.ietf.org; Mon, 04 Oct 2004 09:47:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05505 for ; Mon, 4 Oct 2004 09:47:32 -0400 (EDT) Received: from web51910.mail.yahoo.com ([206.190.39.53]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CETKk-0003uj-3a for rddp@ietf.org; Mon, 04 Oct 2004 09:56:58 -0400 Message-ID: <20041004134701.53764.qmail@web51910.mail.yahoo.com> Received: from [67.169.120.65] by web51910.mail.yahoo.com via HTTP; Mon, 04 Oct 2004 06:47:01 PDT Date: Mon, 4 Oct 2004 06:47:01 -0700 (PDT) From: Sukanta ganguly Subject: Re: [rddp] Rgerading RDMA/SDP and traditional socket apps To: Caitlin Bestler , RDDP In-Reply-To: <5038F2D1-15C0-11D9-9A80-000393814604@asomi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA05505 Cc: Mohan Parthasarathy X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable Hi, I do not think the issue that Mohan is raising is about more traffic across the wire. In essence the traffic on the wire will most probably be less that than the none SDP protocol is concerned. The question of whether the application with synchronous socket approch will have to wait longer for the RNIC to do the DMA onto its local buffer before the app on the other side get controll of its buffer is concerned is a valid one. So the zero copy effect is one aspect that will reduce the amount of real time the synchronous socket I/O app will face latency issues. As far as the reuse of the buffer is concerned, it will depend on a lot of elements, the LAN/WAN link speed will be one, the performance of the remote node will be another one. So o clearly answer this the question, the application should be designed with more memory to be used as during such communication process it may not have the reusebility of its buffers at a very high rate. I think higher memroy consumption will be an element to wonder rather than latency, though latency is also an after effect. Thanks SG --- Caitlin Bestler wrote: >=20 > On Oct 4, 2004, at 5:04 AM, Mohan Parthasarathy > wrote: >=20 > > Hi Mike/Caitlin, > > > > =A0 Thanks for the answers. So, what I understand > is that my assumption > > =A0 that existing socket apps might not have > ownership of the buffer=20 > > when > > =A0 the send completes, was wrong. > > =A0 But, doesn't this mean that send calls will > take more time to=20 > > complete, > > =A0 if the RNIC has to DMA the buffers before > control to the buffer is > > =A0 returned to the caller. Are there any potential > performance issues=20 > > here > > =A0 for existing synchronous sockets ? > > > > Regards, > > Mohan >=20 >=20 > SDP defines multiple transfer procedures precisely > to avoid > this problem. SDP should be configured so that > zero-copy > transfers are only done when doing so will improve > performance. >=20 > For example, when the receive is posted long > enough before > the send for the data sink buffer to have been > advertised the > data source can RDMA Write to the final target > buffer without > any delay. >=20 > SDP inherently involves more wire traffic, but > depending on > the timing of sends and receives this extra traffic > may have no > impact on latency. The benefits of direct placement > should > overcome any penalty for the wire traffic. But that > penalty is > there, which is why local-only optimizations that > achieve direct > placement without wire traffic might be more > efficient, and why > full adaptation to RDMA-aware application logic will > almost > always be more efficient. >=20 >=20 >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp >=20 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Oct 4 11:02:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12061 for ; Mon, 4 Oct 2004 11:02:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEUUx-00077S-JX for rddp-web-archive@ietf.org; Mon, 04 Oct 2004 11:11:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEUHA-0007Jk-Vr; Mon, 04 Oct 2004 10:57:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEUCK-0006GI-2X for rddp@megatron.ietf.org; Mon, 04 Oct 2004 10:52:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11428 for ; Mon, 4 Oct 2004 10:52:17 -0400 (EDT) Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEULQ-0006My-8q for rddp@ietf.org; Mon, 04 Oct 2004 11:01:44 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id 4571111E0A7; Mon, 4 Oct 2004 10:52:16 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97539-02; Mon, 4 Oct 2004 10:52:15 -0400 (EDT) Received: from mail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with SMTP id 3F39511E0AF; Mon, 4 Oct 2004 10:52:15 -0400 (EDT) Received: from 62.90.193.206 (proxying for 62.90.193.206) (SquirrelMail authenticated user cait@asomi.com) by mail52a.simplicato.com with HTTP; Mon, 4 Oct 2004 09:52:15 -0500 (CDT) Message-ID: <17701.62.90.193.206.1096901535.squirrel@mail52a.simplicato.com> In-Reply-To: <20041004134701.53764.qmail@web51910.mail.yahoo.com> References: <5038F2D1-15C0-11D9-9A80-000393814604@asomi.com> <20041004134701.53764.qmail@web51910.mail.yahoo.com> Date: Mon, 4 Oct 2004 09:52:15 -0500 (CDT) Subject: Re: [rddp] Rgerading RDMA/SDP and traditional socket apps From: "Caitlin Bestler" To: "Sukanta ganguly" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at simplicato.com Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.8 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: Mohan Parthasarathy , RDDP X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Sukanta ganguly said: > Hi, > I do not think the issue that Mohan is raising is > about more traffic across the wire. In essence the > traffic on the wire will most probably be less that > than the none SDP protocol is concerned. > The question of whether the application with > synchronous socket approch will have to wait longer > for the RNIC to do the DMA onto its local buffer > before the app on the other side get controll of its > buffer is concerned is a valid one. > So the zero copy effect is one aspect that will > reduce the amount of real time the synchronous socket > I/O app will face latency issues. As far as the reuse > of the buffer is concerned, it will depend on a lot of > elements, the LAN/WAN link speed will be one, the > performance of the remote node will be another one. > So o clearly answer this the question, the > application should be designed with more memory to be > used as during such communication process it may not > have the reusebility of its buffers at a very high > rate. I think higher memroy consumption will be an > element to wonder rather than latency, though latency > is also an after effect. > > > Thanks > SG > Good point. But it is important to remember that this can be more of an accounting issue than an actual savings of memory. Use of SDP, or for that matter an RDMA-aware interface, will have the effect of replacing usage of system buffers with usage of application buffers. The benefit of zero-copying may result in resulting in more total buffering, or it might merely be transferring the same bytes from column A (system buffering) to column B (application buffering). The applicability statement covers these issues, though mostly concentrating on receive buffering. There are applications that truly need the benefits of shared buffering across multiple applications -- and they might be poor candidates for RDMA. For many other applications, and I personally believe most, the system buffer is a bottleneck rather than an enabler. It is much easier to double the amount of RAM in your system than to double its bandwidth. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Oct 4 12:43:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21835 for ; Mon, 4 Oct 2004 12:43:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEW4r-00043p-MU for rddp-web-archive@ietf.org; Mon, 04 Oct 2004 12:52:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEVlM-0006Cy-Bq; Mon, 04 Oct 2004 12:32:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEVdi-0004qg-2d for rddp@megatron.ietf.org; Mon, 04 Oct 2004 12:24:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19848 for ; Mon, 4 Oct 2004 12:24:38 -0400 (EDT) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEVme-0000bG-El for rddp@ietf.org; Mon, 04 Oct 2004 12:34:07 -0400 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel10.hp.com (Postfix) with ESMTP id 7C3CF6801 for ; Mon, 4 Oct 2004 09:24:28 -0700 (PDT) Received: from MK73191c.cup.hp.com ([15.244.203.109]) by esmail.cup.hp.com (8.9.3 (PHNE_29774)/8.8.6) with ESMTP id JAA16731 for ; Mon, 4 Oct 2004 09:22:45 -0700 (PDT) Message-Id: <6.1.2.0.2.20041004085824.01e4eec0@esmail.cup.hp.com> X-Sender: krause@esmail.cup.hp.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 04 Oct 2004 09:22:29 -0700 To: RDDP From: Michael Krause Subject: Re: [rddp] Rgerading RDMA/SDP and traditional socket apps In-Reply-To: <17701.62.90.193.206.1096901535.squirrel@mail52a.simplicato .com> References: <5038F2D1-15C0-11D9-9A80-000393814604@asomi.com> <20041004134701.53764.qmail@web51910.mail.yahoo.com> <17701.62.90.193.206.1096901535.squirrel@mail52a.simplicato.com> Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1126838256==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a --===============1126838256== Content-Type: multipart/alternative; boundary="=====================_90029515==.ALT" --=====================_90029515==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Some things to keep in mind: - Synchronous sockets calls can be completed without any data actually being sent in a traditional network stack. Kernel buffers the data to transmit / re-transmit and the application proceeds normally. This model does not reduce total memory consumption. As link speeds increase, synchronous call will either fail (if non-block set) or stall until kernel memory becomes available as a function of acknowledgement rate. - Asynchronous sockets calls can be completed without any data being sent. This is no different than synchronous sockets calls. However, asynchronous can use the application buffer for retransmission (assuming operation is not completed to the consumer) thus reducing memory pressure in the kernel. - Asynchronous calls (e.g. sockets) map best to RDMA infrastructures and provide optimal performance as well as memory resource management. - Synchronous sockets calls can be supported with SDP and can use the one-copy or zcopy modes to mitigate local as well as end-to-end application latency. - RDMA infrastructure enables OS bypass operation and the ability to mitigate interrupts within the system. This can yield a much more responsive solution as well as more predictable behavior as system load increases. - If applications use synchronous sockets, then they should be designed to deal with the inevitable stall due to a blocked system call. Use of SDP is orthogonal to this and therefore its presence should not have an impact on application design. Yes, programmers often make assumptions about how fast a call will return but if they are creating a robust design, then they should have accounted for the stall.. Note: The OpenGroup Interconnect Software Consortium is defining a set of Sockets extensions that provide asynchronous interfaces and explicit memory management. These extensions will enable Sockets applications to fully exploit the performance benefits of RDMA while enabling the OS to take the guess work out of memory management. These extensions are to be part of the Unix branding so should be available across all Unix and hopefully Linux implementations in the next couple of years. The specification is nearly complete and should be final by the end of this year. Also note that Winsocks has been shipping async sockets support for quite some time and that Winsocks Direct, which is the basis for SDP, is a good proof of concept of the performance benefits. There are a couple of white papers that provide a good overview of what one might expect when running SDP. Mike At 07:52 AM 10/4/2004, Caitlin Bestler wrote: >Sukanta ganguly said: > > Hi, > > I do not think the issue that Mohan is raising is > > about more traffic across the wire. In essence the > > traffic on the wire will most probably be less that > > than the none SDP protocol is concerned. > > The question of whether the application with > > synchronous socket approch will have to wait longer > > for the RNIC to do the DMA onto its local buffer > > before the app on the other side get controll of its > > buffer is concerned is a valid one. > > So the zero copy effect is one aspect that will > > reduce the amount of real time the synchronous socket > > I/O app will face latency issues. As far as the reuse > > of the buffer is concerned, it will depend on a lot of > > elements, the LAN/WAN link speed will be one, the > > performance of the remote node will be another one. > > So o clearly answer this the question, the > > application should be designed with more memory to be > > used as during such communication process it may not > > have the reusebility of its buffers at a very high > > rate. I think higher memroy consumption will be an > > element to wonder rather than latency, though latency > > is also an after effect. > > > > > > Thanks > > SG > > > > >Good point. > >But it is important to remember that this can be more of an >accounting issue than an actual savings of memory. > >Use of SDP, or for that matter an RDMA-aware interface, >will have the effect of replacing usage of system buffers >with usage of application buffers. > >The benefit of zero-copying may result in resulting in >more total buffering, or it might merely be transferring >the same bytes from column A (system buffering) to >column B (application buffering). > >The applicability statement covers these issues, though >mostly concentrating on receive buffering. There are >applications that truly need the benefits of shared buffering >across multiple applications -- and they might be poor >candidates for RDMA. For many other applications, and >I personally believe most, the system buffer is a bottleneck >rather than an enabler. It is much easier to double the >amount of RAM in your system than to double its bandwidth. > > >_______________________________________________ >rddp mailing list >rddp@ietf.org >https://www1.ietf.org/mailman/listinfo/rddp --=====================_90029515==.ALT Content-Type: text/html; charset="us-ascii"
Some things to keep in mind:

- Synchronous sockets calls can be completed without any data actually being sent in a traditional network stack.  Kernel buffers the data to transmit / re-transmit and the application proceeds normally.  This model does not reduce total memory consumption.  As link speeds increase, synchronous call will either fail (if non-block set) or stall until kernel memory becomes available as a function of acknowledgement rate.

- Asynchronous sockets calls can be completed without any data being sent.  This is no different than synchronous sockets calls.  However, asynchronous can use the application buffer for retransmission (assuming operation is not completed to the consumer) thus reducing memory pressure in the kernel.

- Asynchronous calls (e.g. sockets) map best to RDMA infrastructures and provide optimal performance as well as memory resource management.

- Synchronous sockets calls can be supported with SDP and can use the one-copy or zcopy modes to mitigate local as well as end-to-end application latency.

- RDMA infrastructure enables OS bypass operation and the ability to mitigate interrupts within the system.  This can yield a much more responsive solution as well as more predictable behavior as system load increases.

- If applications use synchronous sockets, then they should be designed to deal with the inevitable stall due to a blocked system call.  Use of SDP is orthogonal to this and therefore its presence should not have an impact on application design.  Yes, programmers often make assumptions about how fast a call will return but if they are creating a robust design, then they should have accounted for the stall..


Note: The OpenGroup Interconnect Software Consortium is defining a set of Sockets extensions that provide asynchronous interfaces and explicit memory management.  These extensions will enable Sockets applications to fully exploit the performance benefits of RDMA while enabling the OS to take the guess work out of memory management.  These extensions are to be part of the Unix branding so should be available across all Unix and hopefully Linux implementations in the next couple of years.  The specification is nearly complete and should be final by the end of this year.

Also note that Winsocks has been shipping async sockets support for quite some time and that Winsocks Direct, which is the basis for SDP, is a good proof of concept of the performance benefits.  There are a couple of white papers that provide a good overview of what one might expect when running SDP.

Mike


At 07:52 AM 10/4/2004, Caitlin Bestler wrote:

Sukanta ganguly said:
> Hi,
>   I do not think the issue that Mohan is raising is
> about more traffic across the wire. In essence the
> traffic on the wire will most probably be less that
> than the none SDP protocol is concerned.
>    The question of whether the application with
> synchronous socket approch will have to wait longer
> for the RNIC to do the DMA onto its local buffer
> before the app on the other side get controll of its
> buffer is concerned is a valid one.
>    So the zero copy effect is one aspect that will
> reduce the amount of real time the synchronous socket
> I/O app will face latency issues. As far as the reuse
> of the buffer is concerned, it will depend on a lot of
> elements, the LAN/WAN link speed will be one, the
> performance of the remote node will be another one.
>    So o clearly answer this the question, the
> application should be designed with more memory to be
> used as during such communication process it may not
> have the reusebility of its buffers at a very high
> rate. I think higher memroy consumption will be an
> element to wonder rather than latency, though latency
> is also an after effect.
>
>
> Thanks
> SG
>


Good point.

But it is important to remember that this can be more of an
accounting issue than an actual savings of memory.

Use of SDP, or for that matter an RDMA-aware interface,
will have the effect of replacing usage of system buffers
with usage of application buffers.

The benefit of zero-copying may result in resulting in
more total buffering, or it might merely be transferring
the same bytes from column A (system buffering) to
column B (application buffering).

The applicability statement covers these issues, though
mostly concentrating on receive buffering.  There are
applications that truly need the benefits of shared buffering
across multiple applications -- and they might be poor
candidates for RDMA.  For many other applications, and
I personally believe most, the system buffer is a bottleneck
rather than an enabler.  It is much easier to double the
amount of RAM in your system than to double its bandwidth.


_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp
--=====================_90029515==.ALT-- --===============1126838256== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============1126838256==-- From rddp-bounces@ietf.org Fri Oct 8 11:27:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04243 for ; Fri, 8 Oct 2004 11:27:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFwov-00014K-IN for rddp-web-archive@ietf.org; Fri, 08 Oct 2004 11:38:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFwTL-0005lp-8Z; Fri, 08 Oct 2004 11:15:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFwNg-0004cI-BQ for rddp@megatron.ietf.org; Fri, 08 Oct 2004 11:10:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02747 for ; Fri, 8 Oct 2004 11:10:03 -0400 (EDT) Received: from lilly.csoft.net ([63.111.22.101] helo=mail102.csoft.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CFwXZ-0000cA-HL for rddp@ietf.org; Fri, 08 Oct 2004 11:20:21 -0400 Received: (qmail 48872 invoked from network); 8 Oct 2004 15:09:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (63.111.26.110) by mail102.csoft.net with SMTP; 8 Oct 2004 15:09:59 -0000 Message-ID: <4166ADF1.4070205@fid4.com> Date: Fri, 08 Oct 2004 11:10:41 -0400 From: "Michael C. Cambria" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rddp@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [rddp] IPsec & Markers X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit In MPA, is there any reason why, just like what is allowed with CRC, one cannot have a system administrator knob to disable the use of markers when IPsec is being used? In fact, when I know I'm using IPsec, I rather not have to go through the overhead of markers even when the remote peer sets the M bit in the Request/Reply frame. Regards, MikeC -- Michael C. Cambria email : mcc@fid4.com VoIP : sip:mcc@mcambria.fid4.com FWD : sip:63730@fwd.pulver.com _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Fri Oct 8 12:36:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09179 for ; Fri, 8 Oct 2004 12:36:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFxt7-0002Ti-Cs for rddp-web-archive@ietf.org; Fri, 08 Oct 2004 12:46:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFxWP-0007oO-3Z; Fri, 08 Oct 2004 12:23:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFxQB-0002iL-Bv for rddp@megatron.ietf.org; Fri, 08 Oct 2004 12:16:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08231 for ; Fri, 8 Oct 2004 12:16:42 -0400 (EDT) Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFxa8-000267-UU for rddp@ietf.org; Fri, 08 Oct 2004 12:27:01 -0400 Received: from cacexg11.americas.cpqcorp.net (cacexg11.americas.cpqcorp.net [16.92.1.67]) by palrel13.hp.com (Postfix) with ESMTP id 0AE521C00445; Fri, 8 Oct 2004 09:16:41 -0700 (PDT) Received: from txnexc01.americas.cpqcorp.net ([16.74.7.21]) by cacexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 8 Oct 2004 09:16:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6980.32 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] IPsec & Markers Date: Fri, 8 Oct 2004 11:16:35 -0500 Message-ID: <717252EC3E37AE4392E2614EA24E9F2B0A07A8F0@txnexc01.americas.cpqcorp.net> Thread-Topic: [rddp] IPsec & Markers Thread-Index: AcStS3bdKDSbGMg/QFyn94XPdRGt0gABpAHg From: "Teisberg, Robert" To: "Michael C. Cambria" , X-OriginalArrivalTime: 08 Oct 2004 16:16:36.0771 (UTC) FILETIME=[2F6B6F30:01C4AD52] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Maybe I'm just dense, but how does IPSec solve the problem markers are meant to solve? > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On=20 > Behalf Of Michael C. Cambria > Sent: Friday, October 08, 2004 10:11 AM > To: rddp@ietf.org > Subject: [rddp] IPsec & Markers >=20 >=20 >=20 > In MPA, is there any reason why, just like what is allowed=20 > with CRC, one=20 > cannot have a system administrator knob to disable the use of markers=20 > when IPsec is being used? >=20 > In fact, when I know I'm using IPsec, I rather not have to go through=20 > the overhead of markers even when the remote peer sets the M=20 > bit in the=20 > Request/Reply frame. >=20 > Regards, > MikeC >=20 > --=20 > Michael C. Cambria >=20 > email : mcc@fid4.com > VoIP : sip:mcc@mcambria.fid4.com > FWD : sip:63730@fwd.pulver.com >=20 >=20 >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Fri Oct 8 12:36:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09206 for ; Fri, 8 Oct 2004 12:36:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFxtD-0002Tv-C8 for rddp-web-archive@ietf.org; Fri, 08 Oct 2004 12:46:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFxWQ-0007ps-GS; Fri, 08 Oct 2004 12:23:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFxR0-0003TL-19 for rddp@megatron.ietf.org; Fri, 08 Oct 2004 12:17:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08257 for ; Fri, 8 Oct 2004 12:17:32 -0400 (EDT) Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFxau-00027C-TP for rddp@ietf.org; Fri, 08 Oct 2004 12:27:52 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id 87A4811E093; Fri, 8 Oct 2004 12:17:25 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88876-01; Fri, 8 Oct 2004 12:17:23 -0400 (EDT) Received: from [192.168.1.2] (bzq-198-76.red.bezeqint.net [212.179.198.76]) by host52a.simplicato.com (Postfix) with ESMTP id 9288511E196; Fri, 8 Oct 2004 12:17:16 -0400 (EDT) In-Reply-To: <4166ADF1.4070205@fid4.com> References: <4166ADF1.4070205@fid4.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8503FCE6-1945-11D9-BEBC-000393814604@asomi.com> Content-Transfer-Encoding: 7bit From: Caitlin Bestler Subject: Re: [rddp] IPsec & Markers Date: Fri, 8 Oct 2004 18:17:15 +0200 To: "Michael C. Cambria" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at simplicato.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: rddp@ietf.org X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit On Oct 8, 2004, at 5:10 PM, Michael C. Cambria wrote: > > In MPA, is there any reason why, just like what is allowed with CRC, > one > cannot have a system administrator knob to disable the use of markers > when IPsec is being used? > > In fact, when I know I'm using IPsec, I rather not have to go through > the > overhead of markers even when the remote peer sets the M bit in the > Request/Reply frame. > > Regards, > MikeC > > The Markers are to enable the receiving side to locate the start of MPA Frames even when TCP Segments are received out-of-order. Even with IPSEC enabled a received out-of-order TCP Segment is not necessarily an MPA Frame. Without markers how would the receiver locate the MPA Frame boundary? _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Fri Oct 8 12:47:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09912 for ; Fri, 8 Oct 2004 12:47:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFy47-0002hP-B5 for rddp-web-archive@ietf.org; Fri, 08 Oct 2004 12:58:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFxq3-0003Xw-RK; Fri, 08 Oct 2004 12:43:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFxmU-0002ok-Pp for rddp@megatron.ietf.org; Fri, 08 Oct 2004 12:39:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09435 for ; Fri, 8 Oct 2004 12:39:45 -0400 (EDT) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFxwI-0002XW-Pn for rddp@ietf.org; Fri, 08 Oct 2004 12:50:05 -0400 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel11.hp.com (Postfix) with ESMTP id 6CDA95462 for ; Fri, 8 Oct 2004 09:39:36 -0700 (PDT) Received: from MK73191c.cup.hp.com ([15.244.202.86]) by esmail.cup.hp.com (8.9.3 (PHNE_29774)/8.8.6) with ESMTP id JAA14164 for ; Fri, 8 Oct 2004 09:37:56 -0700 (PDT) Message-Id: <6.1.2.0.2.20041008093628.01d6b980@esmail.cup.hp.com> X-Sender: krause@esmail.cup.hp.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 08 Oct 2004 09:36:57 -0700 To: rddp@ietf.org From: Michael Krause Subject: Re: [rddp] IPsec & Markers In-Reply-To: <4166ADF1.4070205@fid4.com> References: <4166ADF1.4070205@fid4.com> Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1176200790==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab --===============1176200790== Content-Type: multipart/alternative; boundary="=====================_61434287==.ALT" --=====================_61434287==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:10 AM 10/8/2004, Michael C. Cambria wrote: >In MPA, is there any reason why, just like what is allowed with CRC, one >cannot have a system administrator knob to disable the use of markers when >IPsec is being used? > >In fact, when I know I'm using IPsec, I rather not have to go through the >overhead of markers even when the remote peer sets the M bit in the >Request/Reply frame. Marker need is not just data integrity hence use of IPSec is somewhat orthogonal. Mike --=====================_61434287==.ALT Content-Type: text/html; charset="us-ascii" At 08:10 AM 10/8/2004, Michael C. Cambria wrote:

In MPA, is there any reason why, just like what is allowed with CRC, one cannot have a system administrator knob to disable the use of markers when IPsec is being used?

In fact, when I know I'm using IPsec, I rather not have to go through the overhead of markers even when the remote peer sets the M bit in the Request/Reply frame.

Marker need is not just data integrity hence use of IPSec is somewhat orthogonal.

Mike --=====================_61434287==.ALT-- --===============1176200790== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============1176200790==-- From rddp-bounces@ietf.org Fri Oct 8 13:16:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12027 for ; Fri, 8 Oct 2004 13:16:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFyVY-0003PW-MM for rddp-web-archive@ietf.org; Fri, 08 Oct 2004 13:26:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFyFB-0000IL-5E; Fri, 08 Oct 2004 13:09:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFy4n-0006ZI-91 for rddp@megatron.ietf.org; Fri, 08 Oct 2004 12:58:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10669 for ; Fri, 8 Oct 2004 12:58:40 -0400 (EDT) Received: from lilly.csoft.net ([63.111.22.101] helo=mail102.csoft.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CFyER-0002uo-Dn for rddp@ietf.org; Fri, 08 Oct 2004 13:09:00 -0400 Received: (qmail 49308 invoked from network); 8 Oct 2004 16:58:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (63.111.26.110) by mail102.csoft.net with SMTP; 8 Oct 2004 16:58:13 -0000 Message-ID: <4166C750.1000901@fid4.com> Date: Fri, 08 Oct 2004 12:58:56 -0400 From: "Michael C. Cambria" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rddp@ietf.org Subject: Re: [rddp] IPsec & Markers References: <4166ADF1.4070205@fid4.com> <8503FCE6-1945-11D9-BEBC-000393814604@asomi.com> In-Reply-To: <8503FCE6-1945-11D9-BEBC-000393814604@asomi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: Caitlin Bestler X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Caitlin Bestler wrote: > > On Oct 8, 2004, at 5:10 PM, Michael C. Cambria wrote: > >> >> In MPA, is there any reason why, just like what is allowed with CRC, one >> cannot have a system administrator knob to disable the use of markers >> when IPsec is being used? >> >> In fact, when I know I'm using IPsec, I rather not have to go through the >> overhead of markers even when the remote peer sets the M bit in the >> Request/Reply frame. >> >> Regards, >> MikeC >> >> > The Markers are to enable the receiving side to locate the start of > MPA Frames even when TCP Segments are received out-of-order. Out of order or "unaligned"? When the entire FPDU fits in the TCP segment (e.g. aligned), I have no problem locating the start of MPA Frames, in (TCP sequence) order or not. > Even with IPSEC enabled a received out-of-order TCP Segment > is not necessarily an MPA Frame. Without markers how would the > receiver locate the MPA Frame boundary? Sec 5.3 says "MPA MUST encapsulate the ULPDU such that there is exactly one ULPDU contained in one FPDU." With IPsec, there will be no middlebox that can re-segment TCP segments. What I put in the IPsec (e.g.) tunnel will come out the other end of the tunnel. MikeC -- Michael C. Cambria email : mcc@fid4.com VoIP : sip:mcc@mcambria.fid4.com FWD : sip:63730@fwd.pulver.com _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Fri Oct 8 14:28:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18781 for ; Fri, 8 Oct 2004 14:28:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFzdq-0005E1-E9 for rddp-web-archive@ietf.org; Fri, 08 Oct 2004 14:38:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFzHo-0001hp-1X; Fri, 08 Oct 2004 14:16:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFz82-0005nQ-Pq for rddp@megatron.ietf.org; Fri, 08 Oct 2004 14:06:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16848 for ; Fri, 8 Oct 2004 14:06:07 -0400 (EDT) Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFzI2-0004fb-45 for rddp@ietf.org; Fri, 08 Oct 2004 14:16:26 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id A99D411E147; Fri, 8 Oct 2004 14:06:03 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45842-10; Fri, 8 Oct 2004 14:06:02 -0400 (EDT) Received: from [192.168.1.2] (bzq-198-76.red.bezeqint.net [212.179.198.76]) by host52a.simplicato.com (Postfix) with ESMTP id 375B011E079; Fri, 8 Oct 2004 14:05:54 -0400 (EDT) In-Reply-To: <4166C750.1000901@fid4.com> References: <4166ADF1.4070205@fid4.com> <8503FCE6-1945-11D9-BEBC-000393814604@asomi.com> <4166C750.1000901@fid4.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Caitlin Bestler Subject: Re: [rddp] IPsec & Markers Date: Fri, 8 Oct 2004 20:05:55 +0200 To: "Michael C. Cambria" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at simplicato.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: rddp@ietf.org X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit On Oct 8, 2004, at 6:58 PM, Michael C. Cambria wrote: > > > Caitlin Bestler wrote: > >> On Oct 8, 2004, at 5:10 PM, Michael C. Cambria wrote: >>> >>> In MPA, is there any reason why, just like what is allowed with CRC, >>> one >>> cannot have a system administrator knob to disable the use of markers >>> when IPsec is being used? >>> >>> In fact, when I know I'm using IPsec, I rather not have to go >>> through the >>> overhead of markers even when the remote peer sets the M bit in the >>> Request/Reply frame. >>> >>> Regards, >>> MikeC >>> >>> >> The Markers are to enable the receiving side to locate the start of >> MPA Frames even when TCP Segments are received out-of-order. > > Out of order or "unaligned"? When the entire FPDU fits in the TCP > segment (e.g. aligned), > I have no problem locating the start of MPA Frames, in (TCP sequence) > order or not. > You can always find the MPA Frame when it is received in-order. It follows the previous MPA Frame. >> Even with IPSEC enabled a received out-of-order TCP Segment >> is not necessarily an MPA Frame. Without markers how would the >> receiver locate the MPA Frame boundary? > > Sec 5.3 says "MPA MUST encapsulate the ULPDU such that there is > exactly one ULPDU > contained in one FPDU." With IPsec, there will be no middlebox that > can re-segment TCP > segments. What I put in the IPsec (e.g.) tunnel will come out the > other end of the tunnel. > > MikeC You are assuming that the FPDU is submitted directly to IPSEC. If it is submitted to the TCP layer, which submits it to IP layer and then that is submitted to iPSEC then you no longer have a guarantee of alignment. I would not anticipate that many implementations will roto-till IPSEC thru RDMAP. So layering artifacts cannot be ruled out. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Fri Oct 8 14:44:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21206 for ; Fri, 8 Oct 2004 14:44:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFztP-0005iN-Qr for rddp-web-archive@ietf.org; Fri, 08 Oct 2004 14:55:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFzcN-0006zR-Qo; Fri, 08 Oct 2004 14:37:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFzTv-0004C7-31 for rddp@megatron.ietf.org; Fri, 08 Oct 2004 14:28:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18805 for ; Fri, 8 Oct 2004 14:28:43 -0400 (EDT) Received: from ztxmail03.ztx.compaq.com ([161.114.1.207]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFzdr-0005Cp-IJ for rddp@ietf.org; Fri, 08 Oct 2004 14:39:03 -0400 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.81.1.38]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 2C220560; Fri, 8 Oct 2004 13:28:07 -0500 (CDT) Received: from cceexc18.americas.cpqcorp.net ([16.81.1.4]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 8 Oct 2004 13:28:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] IPsec & Markers Date: Fri, 8 Oct 2004 13:28:05 -0500 Message-ID: <4D027986353D1341ADA4F2A4F8A170762EB9911F@cceexc18.americas.cpqcorp.net> Thread-Topic: [rddp] IPsec & Markers Thread-Index: AcStWoRi0Sg6Qx/NRou09nY7iyEG3QACVZfQ From: "Culley, Paul" To: "Michael C. Cambria" , X-OriginalArrivalTime: 08 Oct 2004 18:28:07.0034 (UTC) FILETIME=[8E6205A0:01C4AD64] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: Caitlin Bestler X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable > >> > > The Markers are to enable the receiving side to locate the start of=20 > > MPA Frames even when TCP Segments are received out-of-order. >=20 > Out of order or "unaligned"? When the entire FPDU fits in=20 > the TCP segment (e.g. aligned), I have no problem locating=20 > the start of MPA Frames, in (TCP sequence) order or not. >=20 Unfortunately, just because an FPDU might fit in a TCP segment, does not mean that it MUST always be aligned. It is legal (but unwise) for a sender to segment the TCP stream at other than FPDU boundaries. > > Even with IPSEC enabled a received out-of-order TCP Segment is not=20 > > necessarily an MPA Frame. Without markers how would the receiver=20 > > locate the MPA Frame boundary? >=20 > Sec 5.3 says "MPA MUST encapsulate the ULPDU such that there=20 > is exactly one ULPDU contained in one FPDU." With IPsec,=20 > there will be no middlebox that can re-segment TCP segments. =20 > What I put in the IPsec > (e.g.) tunnel will come out the other end of the tunnel. >=20 > MikeC Same comment as above, while ULPDU (i.e. DDP segments) must fit exactly into FPDU, there is no absolute requirement that FPDUs must fit exactly into TCP segments. >=20 > -- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Fri Oct 8 14:55:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22636 for ; Fri, 8 Oct 2004 14:55:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG03Z-00062M-9k for rddp-web-archive@ietf.org; Fri, 08 Oct 2004 15:05:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFzjD-00008X-U2; Fri, 08 Oct 2004 14:44:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFzcL-0006xQ-Gl for rddp@megatron.ietf.org; Fri, 08 Oct 2004 14:37:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19829 for ; Fri, 8 Oct 2004 14:37:26 -0400 (EDT) Received: from lilly.csoft.net ([63.111.22.101] helo=mail102.csoft.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CFzmJ-0005V9-R0 for rddp@ietf.org; Fri, 08 Oct 2004 14:47:45 -0400 Received: (qmail 47106 invoked from network); 8 Oct 2004 18:37:17 -0000 Received: from unknown (HELO ?127.0.0.1?) (63.111.26.110) by mail102.csoft.net with SMTP; 8 Oct 2004 18:37:17 -0000 Message-ID: <4166DE88.5090008@fid4.com> Date: Fri, 08 Oct 2004 14:38:00 -0400 From: "Michael C. Cambria" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rddp@ietf.org Subject: Re: [rddp] IPsec & Markers References: <4166ADF1.4070205@fid4.com> <8503FCE6-1945-11D9-BEBC-000393814604@asomi.com> <4166C750.1000901@fid4.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Cc: Caitlin Bestler X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Caitlin Bestler wrote: > > On Oct 8, 2004, at 6:58 PM, Michael C. Cambria wrote: > >> >> >> Caitlin Bestler wrote: >> >>> On Oct 8, 2004, at 5:10 PM, Michael C. Cambria wrote: >>> >>>> >>>> In MPA, is there any reason why, just like what is allowed with CRC, >>>> one >>>> cannot have a system administrator knob to disable the use of markers >>>> when IPsec is being used? >>>> >>>> In fact, when I know I'm using IPsec, I rather not have to go >>>> through the >>>> overhead of markers even when the remote peer sets the M bit in the >>>> Request/Reply frame. >>>> >>>> Regards, >>>> MikeC >>>> >>>> >>> The Markers are to enable the receiving side to locate the start of >>> MPA Frames even when TCP Segments are received out-of-order. >> >> >> Out of order or "unaligned"? When the entire FPDU fits in the TCP >> segment (e.g. aligned), >> I have no problem locating the start of MPA Frames, in (TCP sequence) >> order or not. >> > > You can always find the MPA Frame when it is received in-order. > It follows the previous MPA Frame. Agreed. And if out of order, I can use the first to bytes to find the CRC. If the CRC is wrong, I don't have an FPDU. >>> Even with IPSEC enabled a received out-of-order TCP Segment >>> is not necessarily an MPA Frame. Without markers how would the >>> receiver locate the MPA Frame boundary? >> >> >> Sec 5.3 says "MPA MUST encapsulate the ULPDU such that there is >> exactly one ULPDU >> contained in one FPDU." With IPsec, there will be no middlebox that >> can re-segment TCP >> segments. What I put in the IPsec (e.g.) tunnel will come out the >> other end of the tunnel. >> >> MikeC > > > You are assuming that the FPDU is submitted directly to IPSEC. > If it is submitted to the TCP layer, which submits it to IP layer and > then that is submitted to iPSEC then you no longer have a guarantee > of alignment. I'm assuming an "MPA aware TCP". On such, at a minimum, I'd like a knob to not need to waste cycles doing markers, similar to what the draft allows for CRC when IPsec exists. e.g. both sides need to agree. > I would not anticipate that many implementations will roto-till > IPSEC thru RDMAP. So layering artifacts cannot be ruled out. Since IPsec for RDMA cannot be an external box, I can rule out a lot in _my_ implementation of MPA, MPA aware TCP/IP and IPsec. You don't trust it, don't turn the "no need for markers" knob I'm suggesting when connecting to me (or ever.) But even in the general case, I still don't see any problem. BTW, what does "roto-till" mean? :-) Cheers, MikeC -- Michael C. Cambria email : mcc@fid4.com VoIP : sip:mcc@mcambria.fid4.com FWD : sip:63730@fwd.pulver.com _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Fri Oct 8 15:15:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26117 for ; Fri, 8 Oct 2004 15:15:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG0NJ-0006fB-Nv for rddp-web-archive@ietf.org; Fri, 08 Oct 2004 15:25:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG070-0006dG-GP; Fri, 08 Oct 2004 15:09:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFzxk-0003uG-Uq for rddp@megatron.ietf.org; Fri, 08 Oct 2004 14:59:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23611 for ; Fri, 8 Oct 2004 14:59:31 -0400 (EDT) Received: from lilly.csoft.net ([63.111.22.101] helo=mail102.csoft.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CG07i-0006E1-HB for rddp@ietf.org; Fri, 08 Oct 2004 15:09:51 -0400 Received: (qmail 69315 invoked from network); 8 Oct 2004 18:59:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (63.111.26.110) by mail102.csoft.net with SMTP; 8 Oct 2004 18:59:26 -0000 Message-ID: <4166E3B9.5080405@fid4.com> Date: Fri, 08 Oct 2004 15:00:09 -0400 From: "Michael C. Cambria" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rddp@ietf.org Subject: Re: [rddp] IPsec & Markers References: <4D027986353D1341ADA4F2A4F8A170762EB9911F@cceexc18.americas.cpqcorp.net> In-Reply-To: <4D027986353D1341ADA4F2A4F8A170762EB9911F@cceexc18.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: "Culley, Paul" X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Culley, Paul wrote: >>>The Markers are to enable the receiving side to locate the start of >>>MPA Frames even when TCP Segments are received out-of-order. >> >>Out of order or "unaligned"? When the entire FPDU fits in >>the TCP segment (e.g. aligned), I have no problem locating >>the start of MPA Frames, in (TCP sequence) order or not. >> > > Unfortunately, just because an FPDU might fit in a TCP segment, does not > mean that it MUST always be aligned. It is legal (but unwise) for a > sender to segment the TCP stream at other than FPDU boundaries. Agreed. In fact, this happens all the time with an MTU change (e.g. jumbo to 1500). An unacked TCP segment that once fit in an entire FPDU now needs to be retransmitted in many TCP segments. On the receive side, until I have the entire FPDU, so as to calculate the CRC, regardless of what order these TCP segments arrive in I can't do much with the data. In general, (to simplify) a receiver can take any given TCP segment, use the "length" to find the CRC. If the CRC doesn't match, I don't have an FPDU. Regards, MikeC -- Michael C. Cambria email : mcc@fid4.com VoIP : sip:mcc@mcambria.fid4.com FWD : sip:63730@fwd.pulver.com _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Fri Oct 8 17:03:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15366 for ; Fri, 8 Oct 2004 17:03:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG243-0004CH-47 for rddp-web-archive@ietf.org; Fri, 08 Oct 2004 17:14:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG0xe-0006K0-9T; Fri, 08 Oct 2004 16:03:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG0g9-00035W-QZ for rddp@megatron.ietf.org; Fri, 08 Oct 2004 15:45:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29584 for ; Fri, 8 Oct 2004 15:45:24 -0400 (EDT) Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG0px-0007Pu-Uh for rddp@ietf.org; Fri, 08 Oct 2004 15:55:44 -0400 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel12.hp.com (Postfix) with ESMTP id 3DAEA405A8F for ; Fri, 8 Oct 2004 12:45:14 -0700 (PDT) Received: from MK73191c.cup.hp.com ([15.244.204.144]) by esmail.cup.hp.com (8.9.3 (PHNE_29774)/8.8.6) with ESMTP id MAA26959 for ; Fri, 8 Oct 2004 12:43:29 -0700 (PDT) Message-Id: <6.1.2.0.2.20041008124236.0207c140@esmail.cup.hp.com> X-Sender: krause@esmail.cup.hp.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 08 Oct 2004 12:43:51 -0700 To: rddp@ietf.org From: Michael Krause Subject: Re: [rddp] IPsec & Markers In-Reply-To: <4166E3B9.5080405@fid4.com> References: <4D027986353D1341ADA4F2A4F8A170762EB9911F@cceexc18.americas.cpqcorp.net> <4166E3B9.5080405@fid4.com> Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1076597800==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 --===============1076597800== Content-Type: multipart/alternative; boundary="=====================_72528871==.ALT" --=====================_72528871==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I hate to bring this up but from a process perspective, did we not already achieve consensus that markers would always be required? We are getting towards last call so it would be good to avoid re-opening a topic if it has already reached consensus. Mike At 12:00 PM 10/8/2004, Michael C. Cambria wrote: >Culley, Paul wrote: > >>>>The Markers are to enable the receiving side to locate the start of MPA >>>>Frames even when TCP Segments are received out-of-order. >>> >>>Out of order or "unaligned"? When the entire FPDU fits in the TCP >>>segment (e.g. aligned), I have no problem locating the start of MPA >>>Frames, in (TCP sequence) order or not. >>Unfortunately, just because an FPDU might fit in a TCP segment, does not >>mean that it MUST always be aligned. It is legal (but unwise) for a >>sender to segment the TCP stream at other than FPDU boundaries. > >Agreed. In fact, this happens all the time with an MTU change (e.g. jumbo >to 1500). An unacked TCP segment that once fit in an entire FPDU now >needs to be retransmitted in many TCP segments. > >On the receive side, until I have the entire FPDU, so as to calculate the >CRC, regardless of what order these TCP segments arrive in I can't do much >with the data. > >In general, (to simplify) a receiver can take any given TCP segment, use >the "length" to find the CRC. If the CRC doesn't match, I don't have an FPDU. > >Regards, >MikeC > >-- >Michael C. Cambria > >email : mcc@fid4.com > VoIP : sip:mcc@mcambria.fid4.com > FWD : sip:63730@fwd.pulver.com > > >_______________________________________________ >rddp mailing list >rddp@ietf.org >https://www1.ietf.org/mailman/listinfo/rddp --=====================_72528871==.ALT Content-Type: text/html; charset="us-ascii"
I hate to bring this up but from a process perspective, did we not already achieve consensus that markers would always be required?  We are getting towards last call so it would be good to avoid re-opening a topic if it has already reached consensus.

Mike



At 12:00 PM 10/8/2004, Michael C. Cambria wrote:


Culley, Paul wrote:

The Markers are to enable the receiving side to locate the start of MPA Frames even when TCP Segments are received out-of-order.

Out of order or "unaligned"?  When the entire FPDU fits in the TCP segment (e.g. aligned), I have no problem locating the start of MPA Frames, in (TCP sequence) order or not.
Unfortunately, just because an FPDU might fit in a TCP segment, does not
mean that it MUST always be aligned.  It is legal (but unwise) for a
sender to segment the TCP stream at other than FPDU boundaries.

Agreed.  In fact, this happens all the time with an MTU change (e.g. jumbo to 1500).  An unacked TCP segment that once fit in an entire FPDU now needs to be retransmitted in many TCP segments.

On the receive side, until I have the entire FPDU, so as to calculate the CRC, regardless of what order these TCP segments arrive in I can't do much with the data.

In general, (to simplify) a receiver can take any given TCP segment, use the "length" to find the CRC.  If the CRC doesn't match, I don't have an FPDU.

Regards,
MikeC

--
Michael C. Cambria

email : mcc@fid4.com
 VoIP : sip:mcc@mcambria.fid4.com
  FWD : sip:63730@fwd.pulver.com


_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp
--=====================_72528871==.ALT-- --===============1076597800== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============1076597800==-- From rddp-bounces@ietf.org Fri Oct 8 17:35:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19515 for ; Fri, 8 Oct 2004 17:35:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG2YM-0005Sy-Kq for rddp-web-archive@ietf.org; Fri, 08 Oct 2004 17:45:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG2D9-0006Ti-8o; Fri, 08 Oct 2004 17:23:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG1sW-00058y-QR for rddp@megatron.ietf.org; Fri, 08 Oct 2004 17:02:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14931 for ; Fri, 8 Oct 2004 17:02:14 -0400 (EDT) Received: from magic.adaptec.com ([216.52.22.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG22U-00040f-JK for rddp@ietf.org; Fri, 08 Oct 2004 17:12:36 -0400 Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id i98L1hW03064 for ; Fri, 8 Oct 2004 14:01:43 -0700 Received: from aime2k02.adaptec.com (aime2k02.adaptec.com [10.25.8.42]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id i98L1hx31805 for ; Fri, 8 Oct 2004 14:01:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] IPsec & Markers Date: Fri, 8 Oct 2004 14:01:43 -0700 Message-ID: Thread-Topic: [rddp] IPsec & Markers Thread-Index: AcSta1Jkkdvgkb0ZR8SBgGQoYR3oAwAA+g2A From: "Carrier, John" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable hi Mike, why go to the effort of calculating the CRC when the markers = unambiguously define the start of the FPDU?=20 --jc > -----Original Message----- >=20 > MikeC wrote: >=20 >=20 >=20 > In general, (to simplify) a receiver can take any given TCP=20 > segment, use=20 > the "length" to find the CRC. If the CRC doesn't match, I=20 > don't have an=20 > FPDU. >=20 >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Fri Oct 8 22:56:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21915 for ; Fri, 8 Oct 2004 22:56:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG7ZG-0003Jq-On for rddp-web-archive@ietf.org; Fri, 08 Oct 2004 23:06:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG7ME-0000NJ-7P; Fri, 08 Oct 2004 22:53:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG7KZ-0007lh-Mi for rddp@megatron.ietf.org; Fri, 08 Oct 2004 22:51:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21658 for ; Fri, 8 Oct 2004 22:51:33 -0400 (EDT) Received: from lilly.csoft.net ([63.111.22.101] helo=mail102.csoft.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CG7UH-0003EF-IN for rddp@ietf.org; Fri, 08 Oct 2004 23:01:58 -0400 Received: (qmail 97494 invoked from network); 9 Oct 2004 02:51:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (63.111.26.110) by mail102.csoft.net with SMTP; 9 Oct 2004 02:51:08 -0000 Message-ID: <41675216.7050604@fid4.com> Date: Fri, 08 Oct 2004 22:51:02 -0400 From: "Michael C. Cambria" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Krause Subject: Re: [rddp] IPsec & Markers References: <4D027986353D1341ADA4F2A4F8A170762EB9911F@cceexc18.americas.cpqcorp.net> <4166E3B9.5080405@fid4.com> <6.1.2.0.2.20041008124236.0207c140@esmail.cup.hp.com> In-Reply-To: <6.1.2.0.2.20041008124236.0207c140@esmail.cup.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: rddp@ietf.org X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Michael Krause wrote: > > I hate to bring this up but from a process perspective, did we not > already achieve consensus that markers would always be required? We are > getting towards last call so it would be good to avoid re-opening a > topic if it has already reached consensus. The WG only agreed to make IPsec mandatory to implement in San Diego (2 months ago). I never suggested anything other than being able to do for markers what one can do for CRC when running over IPsec. MikeC _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Sat Oct 9 00:14:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26433 for ; Sat, 9 Oct 2004 00:14:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG8mg-0004lW-89 for rddp-web-archive@ietf.org; Sat, 09 Oct 2004 00:24:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG8bT-0005yD-4Q; Sat, 09 Oct 2004 00:13:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG8Xh-00048Y-7v for rddp@megatron.ietf.org; Sat, 09 Oct 2004 00:09:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26155 for ; Sat, 9 Oct 2004 00:09:07 -0400 (EDT) Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG8hh-0004fu-Cb for rddp@ietf.org; Sat, 09 Oct 2004 00:19:33 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id 0B76411E08F; Sat, 9 Oct 2004 00:09:02 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30582-08; Sat, 9 Oct 2004 00:09:01 -0400 (EDT) Received: from [192.168.1.2] (bzq-198-76.red.bezeqint.net [212.179.198.76]) by host52a.simplicato.com (Postfix) with ESMTP id A3EF411E078; Sat, 9 Oct 2004 00:09:00 -0400 (EDT) In-Reply-To: <6.1.2.0.2.20041008124236.0207c140@esmail.cup.hp.com> References: <4D027986353D1341ADA4F2A4F8A170762EB9911F@cceexc18.americas.cpqcorp.net> <4166E3B9.5080405@fid4.com> <6.1.2.0.2.20041008124236.0207c140@esmail.cup.hp.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Caitlin Bestler Subject: Re: [rddp] IPsec & Markers Date: Sat, 9 Oct 2004 06:09:03 +0200 To: Michael Krause X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at simplicato.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: rddp@ietf.org X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable On Oct 8, 2004, at 9:43 PM, Michael Krause wrote: > > I hate to bring this up but from a process perspective, did we not=20 > already > achieve consensus that markers would always be required?=A0 We are > getting towards last call so it would be good to avoid re-opening a=20 > topic > if it has already reached consensus. > > Mike > Agreed. The optimization that has been suggested is that MPA Mode bits be allocated to deal with the case where both ends have an MPA-Aware IPSEC implementation and that the MPA layer is aware the IPSEC is being used (reliably) and the IPSEC mode is such that all PMTU changes will be hidden by IPSEC (i.e. the virtual path's PMTU will never change). Not only do I think the above scenario is unlikely, but if your platform is doing IPSEC in the same device as RDDP/RDMAP and MPA/TCP then why are you worried about the CPU overhead of calculating markers? In my estimation for every 100 connections where this condition could apply the "savings" would be significant for at most one. More importantly there will be billions of connections where these option bits are totally irrelevant. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Oct 11 09:40:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06462 for ; Mon, 11 Oct 2004 09:40:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH0aS-0008Ba-JE for rddp-web-archive@ietf.org; Mon, 11 Oct 2004 09:51:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH0P1-0002ZJ-Sb; Mon, 11 Oct 2004 09:39:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH0NP-0002P2-Q6 for rddp@megatron.ietf.org; Mon, 11 Oct 2004 09:38:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06199 for ; Mon, 11 Oct 2004 09:38:10 -0400 (EDT) Received: from ztxmail05.ztx.compaq.com ([161.114.1.209]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH0Xx-000878-CP for rddp@ietf.org; Mon, 11 Oct 2004 09:49:05 -0400 Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.81.1.59]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id A599DAEAB; Mon, 11 Oct 2004 08:37:37 -0500 (CDT) Received: from cceexc18.americas.cpqcorp.net ([16.81.1.4]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 11 Oct 2004 08:37:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] IPsec & Markers Date: Mon, 11 Oct 2004 08:37:17 -0500 Message-ID: <4D027986353D1341ADA4F2A4F8A170762ED02209@cceexc18.americas.cpqcorp.net> Thread-Topic: [rddp] IPsec & Markers Thread-Index: AcStq5921FP53/O1Tg2mGdPjIOUe1gB6WQng From: "Culley, Paul" To: "Michael C. Cambria" X-OriginalArrivalTime: 11 Oct 2004 13:37:37.0515 (UTC) FILETIME=[78D1BBB0:01C4AF97] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: rddp@ietf.org X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable I'm not sure what more you want to do with markers than you can already do. It is legal for endpoints to specify "Don't transmit Markers to me" (See 'M' bit in MPA connection setup). If your endpoint is certain it can always decode FPDUs without markers, then set this bit to zero. The other end is still free to ask for markers for FPDUs going to it, of course. Of course you must still be prepared for potential alignment breaks, even if you are doing IPSEC, since there is no requirement that senders always align or pack perfectly into segments. And you will always have to process FPDUs in order (to use the length field check) to safely identify the FPDU boundaries. Note that the group agreed that CRC checks were NOT sufficient for FPDU boundary identification. If you were thinking of adding some kind of requirement that when doing IPSEC, senders MUST perfectly align and segment one FPDU to TCP segment, I think that would be a very difficult battle in the IETF. Paul R. Culley HP Fellow 281-514-5543 =20 > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On=20 > Behalf Of Michael C. Cambria > Sent: Friday, October 08, 2004 9:51 PM > To: Krause, Michael R > Cc: rddp@ietf.org > Subject: Re: [rddp] IPsec & Markers >=20 >=20 >=20 > Michael Krause wrote: >=20 > >=20 > > I hate to bring this up but from a process perspective, did we not=20 > > already achieve consensus that markers would always be=20 > required? We=20 > > are getting towards last call so it would be good to avoid=20 > re-opening=20 > > a topic if it has already reached consensus. >=20 > The WG only agreed to make IPsec mandatory to implement in=20 > San Diego (2 months ago). I never suggested anything other=20 > than being able to do for markers what one can do for CRC=20 > when running over IPsec. >=20 > MikeC >=20 >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Oct 11 10:57:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12151 for ; Mon, 11 Oct 2004 10:57:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH1mO-0000z9-9B for rddp-web-archive@ietf.org; Mon, 11 Oct 2004 11:08:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH1ak-00071f-6I; Mon, 11 Oct 2004 10:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH1aY-0006uq-Ri for rddp@megatron.ietf.org; Mon, 11 Oct 2004 10:55:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12057 for ; Mon, 11 Oct 2004 10:55:48 -0400 (EDT) Received: from lilly.csoft.net ([63.111.22.101] helo=mail102.csoft.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CH1l5-0000yD-Te for rddp@ietf.org; Mon, 11 Oct 2004 11:06:45 -0400 Received: (qmail 11690 invoked from network); 11 Oct 2004 14:55:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (63.111.26.110) by mail102.csoft.net with SMTP; 11 Oct 2004 14:55:40 -0000 Message-ID: <416A9EEE.7010202@fid4.com> Date: Mon, 11 Oct 2004 10:55:42 -0400 From: "Michael C. Cambria" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rddp@ietf.org Subject: Re: [rddp] IPsec & Markers References: <4D027986353D1341ADA4F2A4F8A170762ED02209@cceexc18.americas.cpqcorp.net> In-Reply-To: <4D027986353D1341ADA4F2A4F8A170762ED02209@cceexc18.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: "Culley, Paul" X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Culley, Paul wrote: > If you were thinking of adding some kind of requirement that when doing > IPSEC, senders MUST perfectly align and segment one FPDU to TCP segment, > I think that would be a very difficult battle in the IETF. Not must, but MAY (then either communicate this at start or "turn the knob" at boot time. Uncle. :-) > Note that the group agreed that CRC > checks were NOT sufficient for FPDU boundary identification. I never found that in the archives. I found lots of people suggesting this, but not a WG consensus. I was personally convinced when Caitlin Bestler wrote (9 April 2004) "... there is no rule that says a valid DDP Segment could not be the *payload* that is being delivered within a DDP Segment." That said, the archives are unreliable. See the bottom of ftp://ftp.ietf.org/ietf-mail-archive/rddp/. I also got the impression, reading the TSVWG archives, that middleboxes (which would be ruled out with IPsec) were the problem not the RNIC endpoints. That was consistent with my personal experience from pre-DLSw days through "today" of sending frames in TCP and never having one received unaligned when both ends of the connection adhered to the "spec". Hence this thread suggesting "no middlebox, no problem". Regards, MikeC -- Michael C. Cambria email : mcc@fid4.com VoIP : sip:mcc@mcambria.fid4.com FWD : sip:63730@fwd.pulver.com _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Oct 11 13:06:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22630 for ; Mon, 11 Oct 2004 13:06:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH3nS-0003Ve-G7 for rddp-web-archive@ietf.org; Mon, 11 Oct 2004 13:17:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH3bU-0005KH-8I; Mon, 11 Oct 2004 13:04:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH3Vx-0003sR-M8 for rddp@megatron.ietf.org; Mon, 11 Oct 2004 12:59:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21845 for ; Mon, 11 Oct 2004 12:59:10 -0400 (EDT) From: pat_thaler@agilent.com Received: from msgbas1x.cos.agilent.com ([192.25.240.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH3gM-0003LF-Ag for rddp@ietf.org; Mon, 11 Oct 2004 13:10:09 -0400 Received: from enccos5.cos.agilent.com (enccos5.cos.agilent.com [130.29.152.94]) by msgbas1x.cos.agilent.com (Postfix) with SMTP id 001B62366A for ; Mon, 11 Oct 2004 10:58:56 -0600 (MDT) Received: from relcos1.cos.agilent.com (130.29.152.239) by enccos5.cos.agilent.com (Sigaba Gateway v3.83) with ESMTP id 2047431; Mon, 11 Oct 2004 10:59:30 -0600 Received: from wlvdvs01.lvld.agilent.com (wlvdvs01.lvld.agilent.com [148.5.6.4]) by relcos1.cos.agilent.com (Postfix) with ESMTP id AD379D4 for ; Mon, 11 Oct 2004 10:58:56 -0600 (MDT) Received: from wcosbh22.cos.agilent.com ([130.29.152.178]) by wlvdvs01.lvld.agilent.com with InterScan Messaging Security Suite; Mon, 11 Oct 2004 10:58:56 -0600 Received: from wcosmb05.cos.agilent.com ([130.29.152.72]) by wcosbh22.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 11 Oct 2004 10:58:55 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] IPsec & Markers Date: Mon, 11 Oct 2004 10:58:55 -0600 Message-ID: <9418406DEC3B8A4BBDB1B87291D851AF0D22ED@wcosmb05.cos.agilent.com> Thread-Topic: [rddp] IPsec & Markers Thread-Index: AcSta1I24LxnYHk2SO2hI/cMwit17wCR+n0g To: , X-OriginalArrivalTime: 11 Oct 2004 16:58:55.0783 (UTC) FILETIME=[98072B70:01C4AFB3] X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: paul.culley@hp.com X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable MikeC, You started this saying "In MPA, is there any reason why, just like what = is allowed with CRC, one cannot have a system administrator knob to = disable the use of markers=20 when IPsec is being used?" With IPsec on, the CRC may not be there to check. Therefore without a = marker, there may be no CRC to use to check that the segment contained = an aligned FPDU. Regards, Pat -----Original Message----- From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org]On Behalf Of Michael C. Cambria Sent: Friday, 08 October, 2004 12:00 PM To: rddp@ietf.org Cc: Culley, Paul Subject: Re: [rddp] IPsec & Markers In general, (to simplify) a receiver can take any given TCP segment, use = the "length" to find the CRC. If the CRC doesn't match, I don't have an = FPDU. Regards, MikeC --=20 Michael C. Cambria email : mcc@fid4.com VoIP : sip:mcc@mcambria.fid4.com FWD : sip:63730@fwd.pulver.com _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Oct 12 10:21:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22714 for ; Tue, 12 Oct 2004 10:21:23 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHNaw-0005u1-M4 for rddp-web-archive@ietf.org; Tue, 12 Oct 2004 10:25:44 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1CHN2x-0003k5-M9 for rddp-web-archive@ietf.org; Tue, 12 Oct 2004 09:50:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHMtp-0001g7-25; Tue, 12 Oct 2004 09:41:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGNpw-0004pu-58 for rddp@megatron.ietf.org; Sat, 09 Oct 2004 16:29:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07626 for ; Sat, 9 Oct 2004 16:29:01 -0400 (EDT) Received: from dmz1.silverbacksystems.com ([65.172.158.82]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGO07-0005Cx-AE for rddp@ietf.org; Sat, 09 Oct 2004 16:39:35 -0400 Received: from ns.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by dmz1.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 85D2D11609; Sat, 9 Oct 2004 13:27:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 84D8650D2C; Sat, 9 Oct 2004 13:27:54 -0700 (PDT) Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.1.6) id 13328-06F592E7; Sat, 09 Oct 2004 13:27:54 -0700 Received: from someshlap (somesh-lap.corp.silverbacksystems.com [10.0.16.173]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 3224F4BCF3; Sat, 9 Oct 2004 13:27:54 -0700 (PDT) From: "Somesh Gupta" To: , "Black" Subject: RE: [rddp] IPsec & Markers Date: Sat, 9 Oct 2004 13:28:19 -0700 Organization: Silverback Systems, Inc Message-ID: <058d01c4ae3e$86e05270$ad10000a@corp.silverbacksystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.6; AVE: 6.24.0.7; VDF: 6.24.0.88; host: ns.silverbacksystems.com) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 12 Oct 2004 09:41:06 -0400 X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit David, As far as MPA is concerned, a lot of the discussion held previously was under the context of an experimental draft. My assumption is that if it is changes to go on the standards track, it would be entirely open for another round of discussions. Looking forward to your comments on the topic. Thanks, Somesh _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Oct 12 11:07:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28558 for ; Tue, 12 Oct 2004 11:07:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHOQA-0007G6-3S for rddp-web-archive@ietf.org; Tue, 12 Oct 2004 11:18:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHO2D-0000pp-5q; Tue, 12 Oct 2004 10:53:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHNt8-0006am-7b for rddp@megatron.ietf.org; Tue, 12 Oct 2004 10:44:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25747 for ; Tue, 12 Oct 2004 10:44:28 -0400 (EDT) Received: from web51903.mail.yahoo.com ([206.190.39.46]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CHO3p-0006jY-Jx for rddp@ietf.org; Tue, 12 Oct 2004 10:55:37 -0400 Message-ID: <20041012144354.63785.qmail@web51903.mail.yahoo.com> Received: from [67.169.120.65] by web51903.mail.yahoo.com via HTTP; Tue, 12 Oct 2004 07:43:54 PDT Date: Tue, 12 Oct 2004 07:43:54 -0700 (PDT) From: Sukanta ganguly Subject: RE: [rddp] IPsec & Markers To: Somesh Gupta , rddp@ietf.org, Black In-Reply-To: <058d01c4ae3e$86e05270$ad10000a@corp.silverbacksystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Hi, Do we need another draft for finalizing the IPSec & Marker discussion. We have had a lot of discussion but seems like no conclusion is beingh made. We keep on revisiting this topic multiple times. It definitely is time to put a formal, agreeable statement resolving this issue so that we can all conclude happily. Thanks SG --- Somesh Gupta wrote: > David, > > As far as MPA is concerned, a lot of the discussion > held previously was under the context of an > experimental draft. > > My assumption is that if it is changes to go on > the standards track, it would be entirely open > for another round of discussions. > > Looking forward to your comments on the topic. > > Thanks, > Somesh > > > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Oct 12 12:47:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07888 for ; Tue, 12 Oct 2004 12:47:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHPzE-0001x5-Q8 for rddp-web-archive@ietf.org; Tue, 12 Oct 2004 12:58:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHPWl-0000pq-RN; Tue, 12 Oct 2004 12:29:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHPNf-0006CY-8Q for rddp@megatron.ietf.org; Tue, 12 Oct 2004 12:20:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05301 for ; Tue, 12 Oct 2004 12:20:04 -0400 (EDT) Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHPU1-0000kg-No for rddp@ietf.org; Tue, 12 Oct 2004 12:26:43 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id 6814611E1E2; Tue, 12 Oct 2004 12:15:26 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06345-05; Tue, 12 Oct 2004 12:15:23 -0400 (EDT) Received: from mail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with SMTP id 8DD6111E078; Tue, 12 Oct 2004 12:12:44 -0400 (EDT) Received: from 82.166.249.217 (proxying for 82.166.249.217) (SquirrelMail authenticated user cait@asomi.com) by mail52a.simplicato.com with HTTP; Tue, 12 Oct 2004 11:12:44 -0500 (CDT) Message-ID: <47739.82.166.249.217.1097597564.squirrel@mail52a.simplicato.com> In-Reply-To: <20041012144354.63785.qmail@web51903.mail.yahoo.com> References: <058d01c4ae3e$86e05270$ad10000a@corp.silverbacksystems.com> <20041012144354.63785.qmail@web51903.mail.yahoo.com> Date: Tue, 12 Oct 2004 11:12:44 -0500 (CDT) Subject: RE: [rddp] IPsec & Markers From: "Caitlin Bestler" To: "Sukanta ganguly" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at simplicato.com Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.8 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: Somesh Gupta , Black , rddp@ietf.org X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Sukanta ganguly said: > Hi, > Do we need another draft for finalizing the IPSec & > Marker discussion. We have had a lot of discussion but > seems like no conclusion is beingh made. We keep on > revisiting this topic multiple times. > It definitely is time to put a formal, agreeable > statement resolving this issue so that we can all > conclude happily. > > Thanks > SG > If a bit were worth adding, it would have the following meaning: 1) The side setting the bit has an MPA-Aware IPSEC implementation. Hence each IP Datagram submitted to IPSEC for this connection would contain only whole MPA Frames. 2) That in its interface with the local IPSEC stack it will be aware of the original TCP Segment boundaries, and that nothing in the local stack will disturb them. 3) That if this bit is set by the other side, then this side does not want Markers sent to it. The last point in particular strikes me as unlikely. If your peer does not have MPA thru IPSEC tightly integrated you will want markers. Therefore you have to have the logic to process them. This is a major contrast with the normal marker suppression, which is intended to support receivers who did not want to deal with Markers at all. Markers are ugly, and they add code/gate complexity. But they aren't all that computationally intensive. If you have the code/gates to implement them, and you even have number crunching capacity to intergrate IPSEC, then why do you need to suppress receiving markers *if* and only if an "alignment- maintaing IPSEC tunnel" can be validated to exist? The sender already MUST support generating or not generating them. The existing bit was justified by allowing some implementations to totally avoid processing markers on receive when they in fact had no use for them. But using up another option bit for this just doesn't strike me as worthwhile. You do run out of them eventually. -- Caitlin Bestler http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Oct 12 13:00:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08957 for ; Tue, 12 Oct 2004 13:00:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHQBl-0002Dc-PB for rddp-web-archive@ietf.org; Tue, 12 Oct 2004 13:11:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHPsS-0006TI-0B; Tue, 12 Oct 2004 12:51:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHPdJ-0002io-Ip for rddp@megatron.ietf.org; Tue, 12 Oct 2004 12:36:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06786 for ; Tue, 12 Oct 2004 12:36:15 -0400 (EDT) Received: from ztxmail04.ztx.compaq.com ([161.114.1.208]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHPii-0001No-0M for rddp@ietf.org; Tue, 12 Oct 2004 12:41:53 -0400 Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.81.1.58]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 1EB1EDAF; Tue, 12 Oct 2004 11:30:12 -0500 (CDT) Received: from cceexc18.americas.cpqcorp.net ([16.81.1.4]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 12 Oct 2004 11:30:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] IPsec & Markers Date: Tue, 12 Oct 2004 11:30:10 -0500 Message-ID: <4D027986353D1341ADA4F2A4F8A170762ED024B3@cceexc18.americas.cpqcorp.net> Thread-Topic: [rddp] IPsec & Markers Thread-Index: AcSwbYfyX/t/Ov1NSke7/6E8K6JfqgACr6Ug From: "Culley, Paul" To: , "Black" X-OriginalArrivalTime: 12 Oct 2004 16:30:12.0029 (UTC) FILETIME=[BF00EED0:01C4B078] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable As a primary draft author, I don't think that we have arrived at any consensus to change the current draft. If anything, it looks like the opposite is true, no change needed. If anyone disagrees, please post specific text that you would like to see in an updated draft; that will probably help clarify the discussion. Paul R. Culley HP Fellow 281-514-5543 =20 > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On=20 > Behalf Of Sukanta ganguly > Sent: Tuesday, October 12, 2004 9:44 AM > To: Somesh Gupta; rddp@ietf.org; Black > Subject: RE: [rddp] IPsec & Markers >=20 > Hi, > Do we need another draft for finalizing the IPSec & Marker=20 > discussion. We have had a lot of discussion but seems like no=20 > conclusion is beingh made. We keep on revisiting this topic=20 > multiple times. > It definitely is time to put a formal, agreeable statement=20 > resolving this issue so that we can all conclude happily. >=20 > Thanks > SG >=20 > --- Somesh Gupta wrote: >=20 > > David, > >=20 > > As far as MPA is concerned, a lot of the discussion held previously=20 > > was under the context of an experimental draft. > >=20 > > My assumption is that if it is changes to go on the=20 > standards track,=20 > > it would be entirely open for another round of discussions. > >=20 > > Looking forward to your comments on the topic. > >=20 > > Thanks, > > Somesh > >=20 > >=20 > >=20 > > _______________________________________________ > > rddp mailing list > > rddp@ietf.org > > https://www1.ietf.org/mailman/listinfo/rddp > >=20 >=20 >=20 >=20 > =09 > __________________________________ > Do you Yahoo!? > Yahoo! Mail Address AutoComplete - You start. We finish. > http://promotions.yahoo.com/new_mail=20 >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Oct 12 14:43:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18104 for ; Tue, 12 Oct 2004 14:43:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHRmx-0004Wu-0S for rddp-web-archive@ietf.org; Tue, 12 Oct 2004 14:54:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHRYY-0007ed-LL; Tue, 12 Oct 2004 14:39:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHRUo-0006QZ-R1 for rddp@megatron.ietf.org; Tue, 12 Oct 2004 14:35:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17584 for ; Tue, 12 Oct 2004 14:35:38 -0400 (EDT) Received: from magic.adaptec.com ([216.52.22.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHRfc-0004Lr-2L for rddp@ietf.org; Tue, 12 Oct 2004 14:46:48 -0400 Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id i9CIZ6W21691 for ; Tue, 12 Oct 2004 11:35:06 -0700 Received: from aime2k02.adaptec.com (aime2k02.adaptec.com [10.25.8.42]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id i9CIZ6x05823 for ; Tue, 12 Oct 2004 11:35:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] IPsec & Markers Date: Tue, 12 Oct 2004 11:35:06 -0700 Message-ID: Thread-Topic: [rddp] IPsec & Markers Thread-Index: AcSwe0byPfnkJCoTRdS/jKjONlbEfQADf0Lg From: "Carrier, John" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable I agree with Caitlin. The receiver already has all the flexibility it needs. If it doesn't = want markers, for whatever reason, it just clears the flag in the MPA = Req/Rep message. There is no reason to hash out the receivers reasons = for not wanting markers. --jc > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org]On Behalf Of > Caitlin Bestler > Sent: Tuesday, October 12, 2004 9:13 AM > To: Sukanta ganguly > Cc: Somesh Gupta; Black; rddp@ietf.org > Subject: RE: [rddp] IPsec & Markers >=20 >=20 >=20 > Sukanta ganguly said: > > Hi, > > Do we need another draft for finalizing the IPSec & > > Marker discussion. We have had a lot of discussion but > > seems like no conclusion is beingh made. We keep on > > revisiting this topic multiple times. > > It definitely is time to put a formal, agreeable > > statement resolving this issue so that we can all > > conclude happily. > > > > Thanks > > SG > > >=20 > If a bit were worth adding, it would have the following > meaning: >=20 > 1) The side setting the bit has an MPA-Aware IPSEC > implementation. Hence each IP Datagram submitted > to IPSEC for this connection would contain only > whole MPA Frames. > 2) That in its interface with the local IPSEC stack > it will be aware of the original TCP Segment boundaries, > and that nothing in the local stack will disturb them. > 3) That if this bit is set by the other side, then this > side does not want Markers sent to it. >=20 > The last point in particular strikes me as unlikely. > If your peer does not have MPA thru IPSEC tightly > integrated you will want markers. Therefore you have > to have the logic to process them. >=20 > This is a major contrast with the normal marker suppression, > which is intended to support receivers who did not want to > deal with Markers at all. >=20 > Markers are ugly, and they add code/gate complexity. But > they aren't all that computationally intensive. If you have > the code/gates to implement them, and you even have number > crunching capacity to intergrate IPSEC, then why do you need > to suppress receiving markers *if* and only if an "alignment- > maintaing IPSEC tunnel" can be validated to exist? >=20 > The sender already MUST support generating or not generating > them. The existing bit was justified by allowing some > implementations to totally avoid processing markers on > receive when they in fact had no use for them. >=20 > But using up another option bit for this just doesn't > strike me as worthwhile. You do run out of them eventually. >=20 >=20 > -- > Caitlin Bestler > http://asomi.com/ >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Oct 12 17:52:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18823 for ; Tue, 12 Oct 2004 17:52:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHUjp-0004fA-Ej for rddp-web-archive@ietf.org; Tue, 12 Oct 2004 18:03:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHUKg-0003Oa-Sj; Tue, 12 Oct 2004 17:37:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHTmg-0002Vk-62 for rddp@megatron.ietf.org; Tue, 12 Oct 2004 17:02:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09048 for ; Tue, 12 Oct 2004 17:02:12 -0400 (EDT) From: pat_thaler@agilent.com Received: from msgbas1x.cos.agilent.com ([192.25.240.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHTxU-0001lN-9C for rddp@ietf.org; Tue, 12 Oct 2004 17:13:25 -0400 Received: from enccos5.cos.agilent.com (enccos5.cos.agilent.com [130.29.152.94]) by msgbas1x.cos.agilent.com (Postfix) with SMTP id 18D7228C0C for ; Tue, 12 Oct 2004 15:02:11 -0600 (MDT) Received: from relcos2.cos.agilent.com (130.29.152.237) by enccos5.cos.agilent.com (Sigaba Gateway v3.83) with ESMTP id 2170966; Tue, 12 Oct 2004 15:02:45 -0600 Received: from wcosvs03.cos.agilent.com (wcosvs03.cos.agilent.com [130.29.152.233]) by relcos2.cos.agilent.com (Postfix) with ESMTP id 0080C19F for ; Tue, 12 Oct 2004 15:02:06 -0600 (MDT) Received: from wcosbh22.cos.agilent.com ([130.29.152.178]) by wcosvs03.cos.agilent.com with InterScan Messaging Security Suite; Tue, 12 Oct 2004 15:01:25 -0600 Received: from wcosmb05.cos.agilent.com ([130.29.152.72]) by wcosbh22.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 12 Oct 2004 15:01:25 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] IPsec & Markers Date: Tue, 12 Oct 2004 15:01:25 -0600 Message-ID: <9418406DEC3B8A4BBDB1B87291D851AF0E7551@wcosmb05.cos.agilent.com> Thread-Topic: [rddp] IPsec & Markers Thread-Index: AcSwbYfyX/t/Ov1NSke7/6E8K6JfqgACr6UgAAleNWA= To: , , X-OriginalArrivalTime: 12 Oct 2004 21:01:25.0530 (UTC) FILETIME=[A2C41FA0:01C4B09E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable I thought that is where we were too. MikeC cried "uncle" already. I = didn't see anyone else disputing that.=20 I also don't understand Somesh's view that the change in plans for the = draft (experimental to standards track) opens anything up particularly. = We have been working to get the draft to the point where that change = could occur for a long time and I think it was always clear that we = wanted to go that route if we could get the draft to a point that would = allow it. Regards, Pat -----Original Message----- From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org]On Behalf Of Culley, Paul Sent: Tuesday, 12 October, 2004 9:30 AM To: rddp@ietf.org; Black Subject: RE: [rddp] IPsec & Markers As a primary draft author, I don't think that we have arrived at any consensus to change the current draft. If anything, it looks like the opposite is true, no change needed. If anyone disagrees, please post specific text that you would like to see in an updated draft; that will probably help clarify the discussion. Paul R. Culley HP Fellow 281-514-5543 =20 > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On=20 > Behalf Of Sukanta ganguly > Sent: Tuesday, October 12, 2004 9:44 AM > To: Somesh Gupta; rddp@ietf.org; Black > Subject: RE: [rddp] IPsec & Markers >=20 > Hi, > Do we need another draft for finalizing the IPSec & Marker=20 > discussion. We have had a lot of discussion but seems like no=20 > conclusion is beingh made. We keep on revisiting this topic=20 > multiple times. > It definitely is time to put a formal, agreeable statement=20 > resolving this issue so that we can all conclude happily. >=20 > Thanks > SG >=20 > --- Somesh Gupta wrote: >=20 > > David, > >=20 > > As far as MPA is concerned, a lot of the discussion held previously=20 > > was under the context of an experimental draft. > >=20 > > My assumption is that if it is changes to go on the=20 > standards track,=20 > > it would be entirely open for another round of discussions. > >=20 > > Looking forward to your comments on the topic. > >=20 > > Thanks, > > Somesh > >=20 > >=20 > >=20 > > _______________________________________________ > > rddp mailing list > > rddp@ietf.org > > https://www1.ietf.org/mailman/listinfo/rddp > >=20 >=20 >=20 >=20 > =09 > __________________________________ > Do you Yahoo!? > Yahoo! Mail Address AutoComplete - You start. We finish. > http://promotions.yahoo.com/new_mail=20 >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Oct 12 18:25:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23137 for ; Tue, 12 Oct 2004 18:25:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHVGB-0005Nh-Au for rddp-web-archive@ietf.org; Tue, 12 Oct 2004 18:36:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHV09-0003ct-Ax; Tue, 12 Oct 2004 18:20:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHUsJ-0006j5-3E for rddp@megatron.ietf.org; Tue, 12 Oct 2004 18:12:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21422 for ; Tue, 12 Oct 2004 18:12:05 -0400 (EDT) Received: from web51910.mail.yahoo.com ([206.190.39.53]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CHV37-00056l-Aq for rddp@ietf.org; Tue, 12 Oct 2004 18:23:18 -0400 Message-ID: <20041012221135.99896.qmail@web51910.mail.yahoo.com> Received: from [208.35.40.2] by web51910.mail.yahoo.com via HTTP; Tue, 12 Oct 2004 15:11:35 PDT Date: Tue, 12 Oct 2004 15:11:35 -0700 (PDT) From: Sukanta ganguly Subject: RE: [rddp] IPsec & Markers To: pat_thaler@agilent.com, paul.culley@hp.com, rddp@ietf.org, Black_David@emc.com In-Reply-To: <9418406DEC3B8A4BBDB1B87291D851AF0E7551@wcosmb05.cos.agilent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 OOOOh. I think we are all in sync in our understanding based on the responses that happened here. So apologize if that led to a mistargeted fire fight, but I just wanted to make sure that we all knew about the draft direction and that we were not moving ahead with major elements uncovered. ;=) SG --- pat_thaler@agilent.com wrote: > I thought that is where we were too. MikeC cried > "uncle" already. I didn't see anyone else disputing > that. > > I also don't understand Somesh's view that the > change in plans for the draft (experimental to > standards track) opens anything up particularly. We > have been working to get the draft to the point > where that change could occur for a long time and I > think it was always clear that we wanted to go that > route if we could get the draft to a point that > would allow it. > > Regards, > Pat > > -----Original Message----- > From: rddp-bounces@ietf.org > [mailto:rddp-bounces@ietf.org]On Behalf Of > Culley, Paul > Sent: Tuesday, 12 October, 2004 9:30 AM > To: rddp@ietf.org; Black > Subject: RE: [rddp] IPsec & Markers > > > As a primary draft author, I don't think that we > have arrived at any > consensus to change the current draft. If anything, > it looks like the > opposite is true, no change needed. If anyone > disagrees, please post > specific text that you would like to see in an > updated draft; that will > probably help clarify the discussion. > > Paul R. Culley > HP Fellow > 281-514-5543 > > > > -----Original Message----- > > From: rddp-bounces@ietf.org > [mailto:rddp-bounces@ietf.org] On > > Behalf Of Sukanta ganguly > > Sent: Tuesday, October 12, 2004 9:44 AM > > To: Somesh Gupta; rddp@ietf.org; Black > > Subject: RE: [rddp] IPsec & Markers > > > > Hi, > > Do we need another draft for finalizing the > IPSec & Marker > > discussion. We have had a lot of discussion but > seems like no > > conclusion is beingh made. We keep on revisiting > this topic > > multiple times. > > It definitely is time to put a formal, > agreeable statement > > resolving this issue so that we can all conclude > happily. > > > > Thanks > > SG > > > > --- Somesh Gupta > wrote: > > > > > David, > > > > > > As far as MPA is concerned, a lot of the > discussion held previously > > > was under the context of an experimental draft. > > > > > > My assumption is that if it is changes to go on > the > > standards track, > > > it would be entirely open for another round of > discussions. > > > > > > Looking forward to your comments on the topic. > > > > > > Thanks, > > > Somesh > > > > > > > > > > > > _______________________________________________ > > > rddp mailing list > > > rddp@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rddp > > > > > > > > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! Mail Address AutoComplete - You start. We > finish. > > http://promotions.yahoo.com/new_mail > > > > _______________________________________________ > > rddp mailing list > > rddp@ietf.org > > https://www1.ietf.org/mailman/listinfo/rddp > > > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Oct 19 22:00:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15140 for ; Tue, 19 Oct 2004 22:00:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK5y2-00030a-Lw for rddp-web-archive@ietf.org; Tue, 19 Oct 2004 22:12:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK42s-000091-HQ; Tue, 19 Oct 2004 20:09:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJv6F-0004FP-4q for rddp@megatron.ietf.org; Tue, 19 Oct 2004 10:36:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01606 for ; Tue, 19 Oct 2004 10:36:24 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJvIM-0007Fr-Mn for rddp@ietf.org; Tue, 19 Oct 2004 10:49:04 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Tue, 19 Oct 2004 07:36:43 -0700 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 19 Oct 2004 07:36:02 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Oct 2004 07:35:49 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 19 Oct 2004 07:35:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Oct 2004 07:35:51 -0700 Message-ID: Thread-Topic: IETF Internet Draft cut-off dates Thread-Index: AcS16O52ozvsvCyUQSGf/aDRdqpi6w== From: "Jim Pinkerton" To: X-OriginalArrivalTime: 19 Oct 2004 14:35:52.0225 (UTC) FILETIME=[EF222910:01C4B5E8] X-Spam-Score: 0.1 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: BMT@zurich.ibm.com, "Talpey, Thomas" , recio@us.ibm.com Subject: [rddp] IETF Internet Draft cut-off dates X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0250411903==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 This is a multi-part message in MIME format. --===============0250411903== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B5E8.EEBBAAD1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B5E8.EEBBAAD1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Note that the cut-off date for submissions of revisions to existing drafts is October 25th.=20 =20 I'm planning on submitting an update to the security draft (-06). I'm hopeful I can get feedback on the appendices before I do that (Tom?). =20 Are any of the other authors planning on submitting an update? I believe there's at least one in the queue for RDMAP. Others? =20 =20 =20 Jim =20 =20 ------_=_NextPart_001_01C4B5E8.EEBBAAD1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Note that the cut-off date for submissions of = revisions to existing drafts is October 25th.

 

I’m planning on submitting an update to the = security draft (-06). I’m hopeful I can get feedback on the appendices = before I do that (Tom?).

 

Are any of the other authors planning on submitting = an update? I believe there’s at least one in the queue for RDMAP. = Others?

 

 

 

Jim

 

 

------_=_NextPart_001_01C4B5E8.EEBBAAD1-- --===============0250411903== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============0250411903==-- From rddp-bounces@ietf.org Fri Oct 22 18:22:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02719 for ; Fri, 22 Oct 2004 18:22:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL80Q-0005ih-RD for rddp-web-archive@ietf.org; Fri, 22 Oct 2004 18:35:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6xA-00025d-Lh; Fri, 22 Oct 2004 17:28:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6Y6-00048U-6r for rddp@megatron.ietf.org; Fri, 22 Oct 2004 17:02:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15940 for ; Fri, 22 Oct 2004 17:02:05 -0400 (EDT) Received: from fmr01.intel.com ([192.55.52.18] helo=hermes.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL6kw-0000YM-7r for rddp@ietf.org; Fri, 22 Oct 2004 17:15:26 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9ML4Rlf027180; Fri, 22 Oct 2004 21:04:28 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id i9ML1tsm010564; Fri, 22 Oct 2004 21:02:00 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102214015914593 ; Fri, 22 Oct 2004 14:01:59 -0700 Received: from fmsmsx402.amr.corp.intel.com ([132.233.42.200]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 22 Oct 2004 14:01:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rddp] IETF Internet Draft cut-off dates Date: Fri, 22 Oct 2004 14:01:58 -0700 Message-ID: <6315617889C99D4BA7C14687DEC8DB4E0928D471@fmsmsx402.amr.corp.intel.com> Thread-Topic: [rddp] IETF Internet Draft cut-off dates Thread-Index: AcS16O52ozvsvCyUQSGf/aDRdqpi6wCkPo6w From: "Shah, Hemal" To: "Jim Pinkerton" , X-OriginalArrivalTime: 22 Oct 2004 21:01:59.0678 (UTC) FILETIME=[5F4031E0:01C4B87A] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.2 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: BMT@zurich.ibm.com, "Talpey, Thomas" , recio@us.ibm.com X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0799631833==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 This is a multi-part message in MIME format. --===============0799631833== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B87A.5ED78F58" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B87A.5ED78F58 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not planning to submit a new draft of DDP for the upcoming IETF as the last one was submitted in August 2004 and there are no changes from that draft at this point. =20 Hemal =20 ________________________________ From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On Behalf Of Jim Pinkerton Sent: Tuesday, October 19, 2004 7:36 AM To: rddp@ietf.org Cc: BMT@zurich.ibm.com; Talpey, Thomas; recio@us.ibm.com Subject: [rddp] IETF Internet Draft cut-off dates =20 =20 Note that the cut-off date for submissions of revisions to existing drafts is October 25th.=20 =20 I'm planning on submitting an update to the security draft (-06). I'm hopeful I can get feedback on the appendices before I do that (Tom?). =20 Are any of the other authors planning on submitting an update? I believe there's at least one in the queue for RDMAP. Others? =20 =20 =20 Jim =20 =20 ------_=_NextPart_001_01C4B87A.5ED78F58 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not planning to submit a = new draft of DDP for the upcoming IETF as the last one was submitted in = August 2004 and there are no changes from that draft at this = point.

 

Hemal

 

From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On Behalf Of Jim = Pinkerton
Sent: Tuesday, October = 19, 2004 7:36 AM
To: rddp@ietf.org
Cc: BMT@zurich.ibm.com; = Talpey, Thomas; recio@us.ibm.com
Subject: [rddp] IETF = Internet Draft cut-off dates

 

 

Note that the cut-off date for submissions of = revisions to existing drafts is October 25th. =

 

I’m planning on submitting an update to the = security draft (-06). I’m hopeful I can get feedback on the appendices = before I do that (Tom?).

 

Are any of the other authors planning on submitting = an update? I believe there’s at least one in the queue for RDMAP. = Others?

 

 

 

Jim

 

 

------_=_NextPart_001_01C4B87A.5ED78F58-- --===============0799631833== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============0799631833==-- From rddp-bounces@ietf.org Tue Oct 26 19:42:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29967 for ; Tue, 26 Oct 2004 19:42:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMbB8-00032z-Qv for rddp-web-archive@ietf.org; Tue, 26 Oct 2004 19:56:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMZ1k-0005Z9-Mq; Tue, 26 Oct 2004 17:38:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMYRP-0008UU-EW; Tue, 26 Oct 2004 17:01:15 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20633; Tue, 26 Oct 2004 17:01:13 -0400 (EDT) Message-Id: <200410262101.RAA20633@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 26 Oct 2004 17:01:12 -0400 Cc: rddp@ietf.org Subject: [rddp] I-D ACTION:draft-ietf-rddp-problem-statement-05.txt X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Direct Data Placement Working Group of the IETF. Title : Remote Direct Memory Access (RDMA) over IP Problem Statement Author(s) : A. Romanow, et al. Filename : draft-ietf-rddp-problem-statement-05.txt Pages : 21 Date : 2004-10-26 Overhead due to the movement of user data in the end-system network I/O processing path at high speeds is significant, and has limited the use of Internet protocols in interconnection networks and the Internet itself - especially where high bandwidth, low latency and/or low overhead are required by the hosted application. This draft examines this overhead, and addresses an architectural, IP-based "copy avoidance" solution for its elimination, by enabling Remote Direct Memory Access (RDMA). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rddp-problem-statement-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rddp-problem-statement-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rddp-problem-statement-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26161135.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rddp-problem-statement-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rddp-problem-statement-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26161135.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --NextPart-- From rddp-bounces@ietf.org Tue Oct 26 19:45:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00774 for ; Tue, 26 Oct 2004 19:45:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMbDl-0003H4-Ig for rddp-web-archive@ietf.org; Tue, 26 Oct 2004 19:59:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMZ1p-0005ed-3S; Tue, 26 Oct 2004 17:38:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMYRq-0000Np-UB; Tue, 26 Oct 2004 17:01:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20741; Tue, 26 Oct 2004 17:01:40 -0400 (EDT) Message-Id: <200410262101.RAA20741@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 26 Oct 2004 17:01:40 -0400 Cc: rddp@ietf.org Subject: [rddp] I-D ACTION:draft-ietf-rddp-arch-06.txt X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Direct Data Placement Working Group of the IETF. Title : The Architecture of Direct Data Placement (DDP)And Remote Direct Memory Access (RDMA)On Internet Protocols Author(s) : S. Bailey, T. Talpey Filename : draft-ietf-rddp-arch-06.txt Pages : 21 Date : 2004-10-26 This document defines an abstract architecture for Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) protocols to run on Internet Protocol-suite transports. This architecture does not necessarily reflect the proper way to implement such protocols, but is, rather, a descriptive tool for defining and understanding the protocols. DDP allows the efficient placement of data into buffers designated by Upper Layer Protocols (e.g. RDMA). RDMA provides the semantics to enable Remote Direct Memory Access between peers in a way consistent with application requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rddp-arch-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rddp-arch-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rddp-arch-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26161142.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rddp-arch-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rddp-arch-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26161142.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --NextPart--