From exim@www1.ietf.org  Sun Nov  2 13:01:23 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21253
	for <rddp-archive@odin.ietf.org>; Sun, 2 Nov 2003 13:01:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGMXB-0006r8-Ky
	for rddp-archive@odin.ietf.org; Sun, 02 Nov 2003 13:01:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hA2I15iY026353
	for rddp-archive@odin.ietf.org; Sun, 2 Nov 2003 13:01:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGMXB-0006qq-CT
	for rddp-web-archive@optimus.ietf.org; Sun, 02 Nov 2003 13:01:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21208
	for <rddp-web-archive@ietf.org>; Sun, 2 Nov 2003 13:00:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGMX9-000180-00
	for rddp-web-archive@ietf.org; Sun, 02 Nov 2003 13:01:03 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGMX9-00017w-00
	for rddp-web-archive@ietf.org; Sun, 02 Nov 2003 13:01:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGMX8-0006q3-ED; Sun, 02 Nov 2003 13:01:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGMWF-0006oz-Fw
	for rddp@optimus.ietf.org; Sun, 02 Nov 2003 13:00:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21171
	for <rddp@ietf.org>; Sun, 2 Nov 2003 12:59:54 -0500 (EST)
From: Black_David@emc.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGMWD-00017O-00
	for rddp@ietf.org; Sun, 02 Nov 2003 13:00:05 -0500
Received: from [128.221.12.9] (helo=mxic2.corp.emc.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGMWD-00015W-00
	for rddp@ietf.org; Sun, 02 Nov 2003 13:00:05 -0500
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <VNMQ2GBP>; Sun, 2 Nov 2003 12:59:29 -0500
Message-ID: <B459CE1AFFC52D4688B2A5B842CA35EA7A51DE@corpmx14.us.dg.com>
To: rddp@ietf.org
Date: Sun, 2 Nov 2003 12:59:26 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [rddp] Status of drafts: Correction
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>

I originally wrote:

> -- TCP Mapping
> 
> draft-ietf-rddp-mpa-00.txt
> 
> To become a Proposed Standard RFC.
> 
> The major open issues in this draft as of the Vienna meeting involved
> connection initiation/startup.  Substantial meeting time allocated to
> make progress on these issues.

The MPA draft is to become an Informational RFC, not Proposed Standard.
Sorry for any confusion.  Thanks, --David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp



From exim@www1.ietf.org  Wed Nov  5 14:59:20 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20547
	for <rddp-archive@odin.ietf.org>; Wed, 5 Nov 2003 14:59:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHTnz-0001PD-8w
	for rddp-archive@odin.ietf.org; Wed, 05 Nov 2003 14:59:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Jx3xT005403
	for rddp-archive@odin.ietf.org; Wed, 5 Nov 2003 14:59:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHTnz-0001P4-51
	for rddp-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 14:59:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20526
	for <rddp-web-archive@ietf.org>; Wed, 5 Nov 2003 14:58:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHTnw-00029v-00
	for rddp-web-archive@ietf.org; Wed, 05 Nov 2003 14:59:00 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHTnv-00029r-00
	for rddp-web-archive@ietf.org; Wed, 05 Nov 2003 14:58:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHTnw-0001OS-R2; Wed, 05 Nov 2003 14:59:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHTn3-0001Mn-Sq
	for rddp@optimus.ietf.org; Wed, 05 Nov 2003 14:58:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20490
	for <rddp@ietf.org>; Wed, 5 Nov 2003 14:57:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHTn0-000283-00
	for rddp@ietf.org; Wed, 05 Nov 2003 14:58:02 -0500
Received: from thebe.your-site.com ([140.186.45.26])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHTn0-00027Y-00
	for rddp@ietf.org; Wed, 05 Nov 2003 14:58:02 -0500
Received: from asomi.com (64-144-5-25.client.dsl.net [64.144.5.25])
	by thebe.your-site.com (Postfix) with ESMTP id 12CC024515C
	for <rddp@ietf.org>; Wed,  5 Nov 2003 14:58:09 -0500 (EST)
Date: Wed, 5 Nov 2003 13:57:36 -0600
Mime-Version: 1.0 (Apple Message framework v552)
Content-Type: text/plain; charset=US-ASCII; format=flowed
From: Caitlin Bestler <cait@asomi.com>
To: rddp@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <4DC40266-0FCA-11D8-A3F0-003065D48EE0@asomi.com>
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Subject: [rddp] DDP 7.3 - Data Source MUST transmit DDP Messages in order
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Section 7.3 of the DDP spec states that:

    At the Data Source, DDP:

      * MUST transmit DDP Messages in the order they were submitted to
         the DDP layer,


There are two possible interpretations of that requirement, depending
on what the meaning of "transmitting" a DDP Message is.

The liberal interpretation is that the DDP Layer "transmits" a DDP
Message when it presents the last segment in the message to the LLP.

A more complete requirement is that ALL DDP Segments must be presented
for transmission to the LLP *before* the first segment of the next
DDP Message may be submitted.


For most DDP receivers there is no difference between those two
requirements. However, there can be a significant difference for
a DDP receiver that accepts DDP Segments in order from the LLP
and is using a buffer sharing technique such as a Shared Receive
Queue where receive buffers are allocated "on demand".

The latter more restrictive interpretation (which matches what
virtually all implementations would do anyway) would allow a
receiver working with in-order deliveries from the LLP to know
that it would never need to have more than one pending receive
buffer. By the time it needed to allocate the next buffer, the
prior one would be eligible for delivery.

Receivers which process out-of-order would never detect the
difference between the interpretations. Receivers working with
connection specific receive resources (such as a classic
receive queue) would also be indifferent.

However, I believe there is real value in being allowed to
bound the number of pending allocations from a shared receive
queue when DDP Segments are delivered in order by the LLP.
Value that exceeds any imposition the tighter restriction
would place on the Data Source.


I would request the following:

- Does the WG agree that the current wording is compatible
   with both interpretations? Or is the latter interpretation
   locked in by some other language the at I overlooked?

- If there is agreement that the current language is at
   least potentially ambiguous, is there any objection to
   adding the clarification that all DDP Segments for a
   DDP Message must be submitted for transmission to the
   LLP before any Segment for a following DDP Message.




-- 
Caitlin Bestler - cait@asomi.com - http://asomi.com/
http://asomi.com/CaitlinBestlerPublicPgpKey.html


_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp



From exim@www1.ietf.org  Wed Nov  5 16:24:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24514
	for <rddp-archive@odin.ietf.org>; Wed, 5 Nov 2003 16:24:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHV8T-0005UZ-T8
	for rddp-archive@odin.ietf.org; Wed, 05 Nov 2003 16:24:19 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5LOHeJ021099
	for rddp-archive@odin.ietf.org; Wed, 5 Nov 2003 16:24:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHV8T-0005U5-HA
	for rddp-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 16:24:17 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24308
	for <rddp-web-archive@ietf.org>; Wed, 5 Nov 2003 16:24:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHV8R-0003Z6-00
	for rddp-web-archive@ietf.org; Wed, 05 Nov 2003 16:24:15 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHV8R-0003Z3-00
	for rddp-web-archive@ietf.org; Wed, 05 Nov 2003 16:24:15 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHV8Q-0005SC-Ua; Wed, 05 Nov 2003 16:24:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHUYm-0003gr-72
	for rddp@optimus.ietf.org; Wed, 05 Nov 2003 15:47:24 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23199
	for <rddp@ietf.org>; Wed, 5 Nov 2003 15:47:11 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHUYk-000374-00
	for rddp@ietf.org; Wed, 05 Nov 2003 15:47:22 -0500
Received: from palrel13.hp.com ([156.153.255.238])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHUYj-00036V-00
	for rddp@ietf.org; Wed, 05 Nov 2003 15:47:21 -0500
Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164])
	by palrel13.hp.com (Postfix) with ESMTP id 5B74B1C022E3
	for <rddp@ietf.org>; Wed,  5 Nov 2003 12:47:16 -0800 (PST)
Received: from mk731915.cup.hp.com ([15.244.170.93])
	by esmail.cup.hp.com (8.11.1/8.8.6) with ESMTP id hA5Kdpm29584
	for <rddp@ietf.org>; Wed, 5 Nov 2003 12:39:51 -0800 (PST)
Message-Id: <5.1.0.14.2.20031105123757.03c1c778@15.13.130.73>
X-Sender: krause@15.13.130.73
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 05 Nov 2003 12:46:43 -0800
To: rddp@ietf.org
From: Michael Krause <krause@cup.hp.com>
Subject: Re: [rddp] DDP 7.3 - Data Source MUST transmit DDP Messages in
  order
In-Reply-To: <4DC40266-0FCA-11D8-A3F0-003065D48EE0@asomi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>

At 01:57 PM 11/5/2003 -0600, Caitlin Bestler wrote:
>Section 7.3 of the DDP spec states that:
>
>    At the Data Source, DDP:
>
>      * MUST transmit DDP Messages in the order they were submitted to
>         the DDP layer,
>
>
>There are two possible interpretations of that requirement, depending
>on what the meaning of "transmitting" a DDP Message is.
>
>The liberal interpretation is that the DDP Layer "transmits" a DDP
>Message when it presents the last segment in the message to the LLP.
>
>A more complete requirement is that ALL DDP Segments must be presented
>for transmission to the LLP *before* the first segment of the next
>DDP Message may be submitted.
>
>
>For most DDP receivers there is no difference between those two
>requirements. However, there can be a significant difference for
>a DDP receiver that accepts DDP Segments in order from the LLP
>and is using a buffer sharing technique such as a Shared Receive
>Queue where receive buffers are allocated "on demand".
>
>The latter more restrictive interpretation (which matches what
>virtually all implementations would do anyway) would allow a
>receiver working with in-order deliveries from the LLP to know
>that it would never need to have more than one pending receive
>buffer. By the time it needed to allocate the next buffer, the
>prior one would be eligible for delivery.
>
>Receivers which process out-of-order would never detect the
>difference between the interpretations. Receivers working with
>connection specific receive resources (such as a classic
>receive queue) would also be indifferent.
>
>However, I believe there is real value in being allowed to
>bound the number of pending allocations from a shared receive
>queue when DDP Segments are delivered in order by the LLP.
>Value that exceeds any imposition the tighter restriction
>would place on the Data Source.
>
>
>I would request the following:
>
>- Does the WG agree that the current wording is compatible
>   with both interpretations? Or is the latter interpretation
>   locked in by some other language the at I overlooked?
>
>- If there is agreement that the current language is at
>   least potentially ambiguous, is there any objection to
>   adding the clarification that all DDP Segments for a
>   DDP Message must be submitted for transmission to the
>   LLP before any Segment for a following DDP Message.

Implementations should be able to deal with OOO packet delivery and being 
able to target multiple receive buffers if they are posted (shared or 
exclusive).  Given there is no delta in the wire protocol or the expected 
interoperability in this respect, I do not favor trying to tighten how the 
transmitter is implemented as that is potentially delving into the specific 
design options in the hardware.

Mike


_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp



From exim@www1.ietf.org  Wed Nov  5 16:24:46 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24575
	for <rddp-archive@odin.ietf.org>; Wed, 5 Nov 2003 16:24:46 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHV8c-0005bp-Tz
	for rddp-archive@odin.ietf.org; Wed, 05 Nov 2003 16:24:28 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5LOQwS021552
	for rddp-archive@odin.ietf.org; Wed, 5 Nov 2003 16:24:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHV8c-0005bQ-Kg
	for rddp-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 16:24:26 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24350
	for <rddp-web-archive@ietf.org>; Wed, 5 Nov 2003 16:24:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHV8a-0003aA-00
	for rddp-web-archive@ietf.org; Wed, 05 Nov 2003 16:24:24 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHV8a-0003a7-00
	for rddp-web-archive@ietf.org; Wed, 05 Nov 2003 16:24:24 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHV8b-0005av-K6; Wed, 05 Nov 2003 16:24:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHV2v-00053h-1N
	for rddp@optimus.ietf.org; Wed, 05 Nov 2003 16:18:33 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24151
	for <rddp@ietf.org>; Wed, 5 Nov 2003 16:18:20 -0500 (EST)
From: Black_David@emc.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHV2s-0003UM-00
	for rddp@ietf.org; Wed, 05 Nov 2003 16:18:30 -0500
Received: from unk-for-smtp.isus.emc.com ([128.222.32.10] helo=mxic1.corp.emc.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHV2s-0003Tv-00
	for rddp@ietf.org; Wed, 05 Nov 2003 16:18:30 -0500
Received: by mxic1.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <VNMLPSDS>; Wed, 5 Nov 2003 16:18:01 -0500
Message-ID: <B459CE1AFFC52D4688B2A5B842CA35EA7A5209@corpmx14.us.dg.com>
To: rddp@ietf.org
Date: Wed, 5 Nov 2003 16:17:58 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [rddp] RDDP WG Minneapolis agenda
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>

Here's the agenda as of now.  It can still be bashed at the meeting.
Thanks, --David

Minneapolis IETF Meeting
November 10-14, 2003
--------------------

Remote Direct Data Placement WG (rddp)

CHAIR:	David L. Black <Black_David@emc.com>

The RDDP WG works on Remote Direct Data Placement and Remote
Direct Memory Access functionality.  For more information,
please refer to the rddp charter at:

http://www.ietf.org/html.charters/rddp-charter.html

TUESDAY, November 11, 2003, 0900-1130
-------------------------------------
- Agenda Bashing and Administrivia (5 min)
	- Blue Sheets
	- NOTE WELL

- Status of drafts (5 min)

- Applicability Statement (10 min)
	(draft-ietf-rddp-applicability-01.txt)

	Mostly a status update.

- DDP and RDMAP drafts (10 min)
	(draft-ietf-rddp-ddp-01.txt, draft-ietf-rddp-rdmap-01.txt)

	Mostly a status update.  These drafts are close to done and
	are likely to go to WG Last Call before the end of the year.

- SCTP Mapping (10 min)
	(draft-ietf-rddp-sctp-00.txt)

	Despite the -00 version number, this is the fourth version
	of this draft, and it is relatively mature.  There are open
	issues in startup model consistency with the TCP Mapping
	(e.g., Active/Active vs. Active/Passive).

- TCP mapping (30 min)
	(draft-ietf-rddp-mpa-00.txt)

	Newly adopted as a WG draft in Vienna, this draft is also on
	its fourth major version, but there are open issues in the
	area of connection initiation/startup.

- Security (75 min)
	(draft-ietf-rddp-security-00.txt)

	Time allocated reflects the importance of progress on this draft.

- iSER/DA drafts (5 min)
	(draft-ko-iwarp-iser-00.txt, draft-chadalapaka-iwarp-da-00.txt)

	These two individual submissions concern iSCSI extensions for use
	of RDMA.  The authors would like this work to be pursued by the
	IETF.  This time slot provides for a quick description of what
	these drafts cover; those interested should follow up with the
	authors directly (e.g., over lunch).

_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp



From exim@www1.ietf.org  Wed Nov  5 17:47:21 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28052
	for <rddp-archive@odin.ietf.org>; Wed, 5 Nov 2003 17:47:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHWQb-0003vP-36
	for rddp-archive@odin.ietf.org; Wed, 05 Nov 2003 17:47:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Ml5vA015081
	for rddp-archive@odin.ietf.org; Wed, 5 Nov 2003 17:47:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHWQa-0003vA-V8
	for rddp-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 17:47:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28019
	for <rddp-web-archive@ietf.org>; Wed, 5 Nov 2003 17:46:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHWQY-00054C-00
	for rddp-web-archive@ietf.org; Wed, 05 Nov 2003 17:47:02 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHWQX-000549-00
	for rddp-web-archive@ietf.org; Wed, 05 Nov 2003 17:47:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHWQZ-0003u3-73; Wed, 05 Nov 2003 17:47:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHWQD-0003sO-RP
	for rddp@optimus.ietf.org; Wed, 05 Nov 2003 17:46:41 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28009;
	Wed, 5 Nov 2003 17:46:27 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHWQA-00053w-00; Wed, 05 Nov 2003 17:46:38 -0500
Received: from atlrel8.hp.com ([156.153.255.206])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHWQA-00053t-00; Wed, 05 Nov 2003 17:46:38 -0500
Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26])
	by atlrel8.hp.com (Postfix) with ESMTP
	id 1B4851C02BCE; Wed,  5 Nov 2003 17:46:38 -0500 (EST)
Received: from swathi.rose.hp.com (dhcp-roseor-bdi217.rose.hp.com [15.23.138.217]) by rosemail.rose.hp.com with ESMTP (8.7.1/8.7.3 SMKit7.02) id OAA00614; Wed, 5 Nov 2003 14:46:36 -0800 (PST)
Message-Id: <6.0.0.22.1.20031105142251.02a97c90@rosemail.rose.hp.com>
X-Sender: cbm@rosemail.rose.hp.com
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
Date: Wed, 05 Nov 2003 14:46:31 -0800
To: Black_David@emc.com, ips@ietf.org, rddp@ietf.org
From: "Mallikarjun C." <cbm@rose.hp.com>
Cc: nfsv4@ietf.org
In-Reply-To: <B459CE1AFFC52D4688B2A5B842CA35EA7A518F@corpmx14.us.dg.com>
References: <B459CE1AFFC52D4688B2A5B842CA35EA7A518F@corpmx14.us.dg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [rddp] Re: [Ips] iSCSI over RDMA (iSER and DA) Internet Drafts
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>

Thanks David.

 >and solicit interest in working on them (e.g.,
 >organize an informal meeting [aka "bar BOF"] to discuss
 >further).

Sorry for the cross-post, but I'd like to hear in short order
(< 24 hours) from all those who can attend an informal
iSER/DA discussion/presentation *if one is organized*
along the lines of what David suggested.

I know it's perhaps too late for such a poll, but if enough
folks respond within a day, some of us would like to take
the time to present, educate and be educated.

Please send me a short email *offline* if you can attend.
All the folks on this distribution are welcome.

If I see enough responses, I will send an annoucement
with logistics by 11/6 evening PT.  In the absence of such
a separate discussion, of course, the 5 minute agenda
time in the RDDP meeting will be the only discussion
time as a group on iSER/DA (excluding the hallway
conversations).

Thanks.

Mallikarjun


At 11:01 AM 10/24/2003, Black_David@emc.com wrote:
>On the IPS list, Mallikarjun asked:
>
> > Could you please recommend the most optimal course
> > of action to request and enhance the WG charter?
>
>IETF being IETF, the world of "rough consensus and
>running code", I have no idea what "the most optimal
>course of action" would be, or whether it even exists :-).
>
>The scope of an IETF WG's activities and the items on
>which it works are managed by the Area Directors and
>the IESG via the WG's charter, among other means.  My
>understanding of the Transport ADs' views is that the
>IP Storage WG has been very successful in what the WG
>set out to do, and the time has come to finish up the
>current work, declare victory and move on (with the WG
>either going dormant or being concluded).  Of course the
>ADs always reserve the right to change their minds based
>on new information, etc., and my understanding may be
>less than perfect.
>
>The people advocating addition of work on iSCSI over RDMA
>seem to be spending a lot of energy on where the work should
>be done (process) and much less on whether and why it should
>be done (technical merits).  In my experience, these two topics
>are best pursued in the opposite order.  Specifically, the first
>decision (ADs and IESG as appropriate) should be whether the
>work is to be done and with what scope; if that is decided
>in the affirmative, then matters of where and how can then
>be worked out in a reasonable fashion.
>
>Given this, I do have some advice to offer:
>(1) A promising path towards undertaking iSCSI over RDMA work
>         in the IETF involves a BOF, e.g., in Seoul.  Those
>         interested in such a BOF should approach the Transport
>         Area Directors about organizing and holding one (but
>         first read the material on BOFs in RFC 2418).  By the
>         time of the Seoul meeting week, the rddp WG should be
>         done or close to done with most of the drafts on which
>         iSCSI over RDMA depends, providing a firmer foundation
>         for the proposed work.
>- One of the things that inclines ADs and the IESG towards
>         approval of work is the existence of an open community of
>         people interested in the work, the broader the better.
>         IETF meeting weeks are a good opportunity to solicit
>         interest in possible work towards forming/broadening such
>         a community (e.g., hallway discussion).  In furtherance
>         of this, in my role as RDDP WG chair I have already promised
>         the iSER/DA draft authors a 5 minute slot in the RDDP WG
>         meeting in Minneapolis to briefly describe what the drafts
>         are about and solicit interest in working on them (e.g.,
>         organize an informal meeting [aka "bar BOF"] to discuss
>         further).
>
>For those who are new to this topic, the iSER and DA drafts
>on the topic of iSCSI over RDMA are:
>
>http://www.ietf.org/internet-drafts/draft-ko-iwarp-iser-00.txt
>http://www.ietf.org/internet-drafts/draft-chadalapaka-iwarp-da-00.txt
>
>Thanks,
>--David (IPS WG co-chair, RDDP WG chair)
>----------------------------------------------------
>David L. Black, Senior Technologist
>EMC Corporation, 176 South St., Hopkinton, MA  01748
>+1 (508) 293-7953             FAX: +1 (508) 293-7786
>black_david@emc.com        Mobile: +1 (978) 394-7754
>----------------------------------------------------
>
>_______________________________________________
>Ips mailing list
>Ips@ietf.org
>https://www1.ietf.org/mailman/listinfo/ips


_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp



From exim@www1.ietf.org  Thu Nov  6 11:12:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15773
	for <rddp-archive@odin.ietf.org>; Thu, 6 Nov 2003 11:12:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHmjp-000060-H0
	for rddp-archive@odin.ietf.org; Thu, 06 Nov 2003 11:12:02 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6GC1OC000364
	for rddp-archive@odin.ietf.org; Thu, 6 Nov 2003 11:12:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHmjp-00005n-Dd
	for rddp-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 11:12:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15737
	for <rddp-web-archive@ietf.org>; Thu, 6 Nov 2003 11:11:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHmjo-0003HB-00
	for rddp-web-archive@ietf.org; Thu, 06 Nov 2003 11:12:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHmjo-0003H7-00
	for rddp-web-archive@ietf.org; Thu, 06 Nov 2003 11:12:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHmjp-00005L-IC; Thu, 06 Nov 2003 11:12:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHmjI-0008U7-CK
	for rddp@optimus.ietf.org; Thu, 06 Nov 2003 11:11:33 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15656
	for <rddp@ietf.org>; Thu, 6 Nov 2003 11:11:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHmjF-0003GA-00
	for rddp@ietf.org; Thu, 06 Nov 2003 11:11:25 -0500
Received: from thebe.your-site.com ([140.186.45.26])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHmjF-0003FZ-00
	for rddp@ietf.org; Thu, 06 Nov 2003 11:11:25 -0500
Received: from asomi.com (64-144-5-25.client.dsl.net [64.144.5.25])
	by thebe.your-site.com (Postfix) with ESMTP
	id B8517244F04; Thu,  6 Nov 2003 11:11:32 -0500 (EST)
Date: Thu, 6 Nov 2003 10:11:01 -0600
Subject: RE: [rddp] DDP 7.3 - Data Source MUST transmit DDP Messages in order
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: Michael Krause <krause@cup.hp.com>
To: rddp@ietf.org
From: Caitlin Bestler <cait@asomi.com>
Content-Transfer-Encoding: 7bit
Message-Id: <D0989534-1073-11D8-A3F0-003065D48EE0@asomi.com>
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Michael Krause's replied to my post as follows:

 >> I would request the following:
 >>
 >> - Does the WG agree that the current wording is compatible
 >>   with both interpretations? Or is the latter interpretation
 >>   locked in by some other language the at I overlooked?

 >> - If there is agreement that the current language is at
 >>   least potentially ambiguous, is there any objection to
 >>   adding the clarification that all DDP Segments for a
 >>   DDP Message must be submitted for transmission to the
 >>   LLP before any Segment for a following DDP Message.

 > Implementations should be able to deal with OOO packet delivery and 
being
 > able to target multiple receive buffers if they are posted (shared or 
  exclusive).
 > Given there is no delta in the wire protocol or the expected  
interoperability in
 > this respect, I do not favor trying to tighten how the  transmitter 
is implemented
 > as that is potentially delving into the specific  design options in 
the hardware.
 >
 > Mike

Generally, I am in full agreement. Receivers should be as flexible as 
possible
and senders should be given as much freedom as possible.

But the purpose of that is to allow senders to find potential 
optimizations
in ways that might not have been obvious. For example, mandating that a
message MUST be segmented in a certain way would block a sender from 
optimizing
for a DDP Segment that might have piggy-packed in the same SCTP Packet 
or TCP
Segment that was already partially filled.

But I'm not sure I can see any benefit to the senders of working ahead,
especially when the last segments must be sent in order and when for 
many
ULPs almost all untagged messages will fit in a single segment.

On the receiving side, however, the restriction can be beneficial to an
entire *class* of implementations -- those that ride on top of optimized
TCP solutions.

Since we have made it clear that the receiver does not have to 
pre-commit
receive buffer for untagged messages (as in the class receive queue) we
have implicitly allowed for receivers that must fetch buffers "on 
demand".

Whatever implementation is used, clearly having a limit on the number of
fetched buffers that have not completed will result in a simpler 
problem.

Simplifying the problem is legitimate. Yes it benefits certain 
implementations,
but that is because it simplified the problem.

Admittedly, the proposed restriction is of virtually no benefit to
implementations that process DDP Segments in arrival order. For that
reason it would be wrong to impose any costs on those implementations
for this feature. But there is no impact on out-of-order receivers.

The *only* impact is that it might block hyper-aggressive re-ordering
of unsent pending DDP Segments. Even with this proposed additional
language, such re-ordering is still possible *within* an untagged
message and with tagged segments. In my opinion that is more than
enough slack for potential optimizations (in fact I suspect that
very few implementations are even considering such optimizations).






-- 
Caitlin Bestler - cait@asomi.com - http://asomi.com/
http://asomi.com/CaitlinBestlerPublicPgpKey.html


_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp



From exim@www1.ietf.org  Thu Nov 13 13:18:24 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11319
	for <rddp-archive@odin.ietf.org>; Thu, 13 Nov 2003 13:18:24 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKM2g-0001P3-TA
	for rddp-archive@odin.ietf.org; Thu, 13 Nov 2003 13:18:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hADII6SK005389
	for rddp-archive@odin.ietf.org; Thu, 13 Nov 2003 13:18:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKM2g-0001Op-5i
	for rddp-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 13:18:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11307
	for <rddp-web-archive@ietf.org>; Thu, 13 Nov 2003 13:17:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKM2e-0002Cf-00
	for rddp-web-archive@ietf.org; Thu, 13 Nov 2003 13:18:04 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKM2d-0002Cb-00
	for rddp-web-archive@ietf.org; Thu, 13 Nov 2003 13:18:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKM2c-0001O4-2i; Thu, 13 Nov 2003 13:18:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKM1g-0001NL-3I
	for rddp@optimus.ietf.org; Thu, 13 Nov 2003 13:17:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11293;
	Thu, 13 Nov 2003 13:16:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKM1d-0002CE-00; Thu, 13 Nov 2003 13:17:01 -0500
Received: from palrel10.hp.com ([156.153.255.245])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKM1d-0002CB-00; Thu, 13 Nov 2003 13:17:01 -0500
Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26])
	by palrel10.hp.com (Postfix) with ESMTP
	id 1286B1C02534; Thu, 13 Nov 2003 10:17:00 -0800 (PST)
Received: from swathi.rose.hp.com (dhcp-roseor-bec059.rose.hp.com [15.23.142.59]) by rosemail.rose.hp.com with ESMTP (8.7.1/8.7.3 SMKit7.02) id KAA14734; Thu, 13 Nov 2003 10:16:59 -0800 (PST)
Message-Id: <6.0.0.22.1.20031113101359.02a898a0@rosemail.rose.hp.com>
X-Sender: cbm@rosemail.rose.hp.com
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
Date: Thu, 13 Nov 2003 10:16:58 -0800
To: ips@ietf.org, rddp@ietf.org
From: "Mallikarjun C." <cbm@rose.hp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [rddp] iSCSI/RDMA slides from IETF-58
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>

All:

The iSCSI/RDMA (DA and iSER) slides I presented
in the RDDP WG meeting at IETF-58 in Minneapolis
are posted at:

http://storage-arch.hp.com/iSCSI_over_RDMA_IETF_58.pdf
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard, Roseville
cbm [at] rose.hp.com


_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp



From exim@www1.ietf.org  Thu Nov 13 17:05:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23137
	for <rddp-archive@odin.ietf.org>; Thu, 13 Nov 2003 17:05:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKPaK-0001gN-MQ
	for rddp-archive@odin.ietf.org; Thu, 13 Nov 2003 17:05:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hADM54jB006465
	for rddp-archive@odin.ietf.org; Thu, 13 Nov 2003 17:05:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKPaJ-0001gC-Fm
	for rddp-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 17:05:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23093
	for <rddp-web-archive@ietf.org>; Thu, 13 Nov 2003 17:04:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKPaH-0006GG-00
	for rddp-web-archive@ietf.org; Thu, 13 Nov 2003 17:05:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKPaG-0006GD-00
	for rddp-web-archive@ietf.org; Thu, 13 Nov 2003 17:05:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKPaG-0001fo-Vh; Thu, 13 Nov 2003 17:05:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKPa3-0001fO-Q6
	for rddp@optimus.ietf.org; Thu, 13 Nov 2003 17:04:47 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23075
	for <rddp@ietf.org>; Thu, 13 Nov 2003 17:04:35 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKPa1-0006Fq-00
	for rddp@ietf.org; Thu, 13 Nov 2003 17:04:45 -0500
Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKPa1-0006Fj-00
	for rddp@ietf.org; Thu, 13 Nov 2003 17:04:45 -0500
Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP
  (SMTPD32-7.00) id A102D00D00DC; Thu, 13 Nov 2003 17:09:06 -0500
From: "Barry Reinhold" <bbr@lampreynetworks.com>
To: "RDDP" <rddp@ietf.org>
Date: Thu, 13 Nov 2003 17:04:42 -0500
Message-ID: <002c01c3aa32$241e2d30$467fa8c0@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
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [rddp] Transmission of RsvdULP in each segment or an RDDP message
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Folks,
	I'm playing a bit a catch up here and may be exhuming old
bodies, but could someone motivate the rational behind this pp? 

        The RsvdULP field is opaque to the DDP protocol and can be 
        structured in any way by the ULP. At the Data Source, DDP MUST 
        set RsvdULP Field to the value specified by the ULP. It is 
        transferred unmodified from the Data Source to the Data Sink. 
        At the Data Sink, DDP MUST provide the RsvdULP field to the ULP 
        when the DDP Message is delivered. Each DDP Segment within a 
        specific DDP Message MUST contain the same value for this 
        field. 

In particular I don't understand the motivation for the last sentence.
>From a conformance point of view I have to test this statement for both
the xmitter and receiver. For the receiver this would be done by
generating a DDP message with N DDP segments. I would then run N trials
in which one of the N segments has a modified RsvdULP field in the
header. This would verify that the receiving DDP entity checked the
field (The receiver check has to be done given the MUST -- since MUST is
only used for requirements that impact interoperability - this is an
implicit rule that the receiver checks or uses this -- otherwise it
doesn't impact interoperability). I'm sure people are not planning on
having their receiver code check this.

I think a better way to write this would be to have the receiver only
look at this field when the L bit is set. If the L bit is not set the
field should be ignored. 

If there is some other requirement that forces this field to be valid
for each segment in a message it would make sense to word this so that
the requirement is only on the transmitter. (i.e. the transmitter MUST)

Barry Reinhold
Lamprey Networks
bbr@lampreynetworks.com
(603) 868-8411
 



_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp



From exim@www1.ietf.org  Thu Nov 13 20:51:13 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04198
	for <rddp-archive@odin.ietf.org>; Thu, 13 Nov 2003 20:51:13 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKT6s-0002Rg-At
	for rddp-archive@odin.ietf.org; Thu, 13 Nov 2003 20:50:54 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE1osa3009396
	for rddp-archive@odin.ietf.org; Thu, 13 Nov 2003 20:50:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKT6s-0002RT-7k
	for rddp-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 20:50:54 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04146
	for <rddp-web-archive@ietf.org>; Thu, 13 Nov 2003 20:50:42 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKT6p-0002Jf-00
	for rddp-web-archive@ietf.org; Thu, 13 Nov 2003 20:50:51 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKT6p-0002JY-00
	for rddp-web-archive@ietf.org; Thu, 13 Nov 2003 20:50:51 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKT61-0002Om-Sc; Thu, 13 Nov 2003 20:50:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKT53-0002Ns-5I
	for rddp@optimus.ietf.org; Thu, 13 Nov 2003 20:49:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04121
	for <rddp@ietf.org>; Thu, 13 Nov 2003 20:48:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKT50-0002IZ-00
	for rddp@ietf.org; Thu, 13 Nov 2003 20:48:58 -0500
Received: from mail1.microsoft.com ([131.107.3.125])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKT50-0002II-00
	for rddp@ietf.org; Thu, 13 Nov 2003 20:48:58 -0500
Received: from mail5.microsoft.com ([157.54.6.156]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0);
	 Thu, 13 Nov 2003 17:48:32 -0800
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039);
	 Thu, 13 Nov 2003 17:48:19 -0800
Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 Nov 2003 17:48:27 -0800
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069);
	 Thu, 13 Nov 2003 17:48:27 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069);
	 Thu, 13 Nov 2003 17:48:05 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069);
	 Thu, 13 Nov 2003 17:49:15 -0800
x-mimeole: Produced By Microsoft Exchange V6.5.7097.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] Transmission of RsvdULP in each segment or an RDDP message
Date: Thu, 13 Nov 2003 17:47:47 -0800
Message-ID: <E6564B8F86852D46A4E98C485FB33B8F05778E41@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [rddp] Transmission of RsvdULP in each segment or an RDDP message
Thread-Index: AcOqMkqh0EiDIRXLS1Gb0pznKCpzqgABrmgA
From: "Jim Pinkerton" <jpink@windows.microsoft.com>
To: "Barry Reinhold" <bbr@lampreynetworks.com>, "RDDP" <rddp@ietf.org>
X-OriginalArrivalTime: 14 Nov 2003 01:49:15.0523 (UTC) FILETIME=[82836D30:01C3AA51]
Content-Transfer-Encoding: quoted-printable
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable


Barry,

The motivation for having the same value in each of the DDP segments was
to allow the ULP to provide information that might need to be checked on
the first segment (or intermediate segment if the segment arrives out of
order). For example, for RDMAP the RV (RDMA Version) field.=20

Also, for debugging it is extremely convenient to have the RDMAP opcode
valid in all segments rather than just the last one.

As to checking on receive, I agree that requiring all implementations to
verify that all segments contain the same value was not intended (other
folks, please pipe in if I got this wrong), and is onerous.

So I think you're suggesting something like:

"The transmitter MUST ensure each DDP Segment within a specific DDP
Message contains the same value for this field."

Seems reasonable to me.



Jim



> -----Original Message-----
> From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of
Barry
> Reinhold
> Sent: Thursday, November 13, 2003 2:05 PM
> To: RDDP
> Subject: [rddp] Transmission of RsvdULP in each segment or an RDDP
message
>=20
> Folks,
> 	I'm playing a bit a catch up here and may be exhuming old
> bodies, but could someone motivate the rational behind this pp?
>=20
>         The RsvdULP field is opaque to the DDP protocol and can be
>         structured in any way by the ULP. At the Data Source, DDP MUST
>         set RsvdULP Field to the value specified by the ULP. It is
>         transferred unmodified from the Data Source to the Data Sink.
>         At the Data Sink, DDP MUST provide the RsvdULP field to the
ULP
>         when the DDP Message is delivered. Each DDP Segment within a
>         specific DDP Message MUST contain the same value for this
>         field.
>=20
> In particular I don't understand the motivation for the last sentence.
> >From a conformance point of view I have to test this statement for
both
> the xmitter and receiver. For the receiver this would be done by
> generating a DDP message with N DDP segments. I would then run N
trials
> in which one of the N segments has a modified RsvdULP field in the
> header. This would verify that the receiving DDP entity checked the
> field (The receiver check has to be done given the MUST -- since MUST
is
> only used for requirements that impact interoperability - this is an
> implicit rule that the receiver checks or uses this -- otherwise it
> doesn't impact interoperability). I'm sure people are not planning on
> having their receiver code check this.
>=20
> I think a better way to write this would be to have the receiver only
> look at this field when the L bit is set. If the L bit is not set the
> field should be ignored.
>=20
> If there is some other requirement that forces this field to be valid
> for each segment in a message it would make sense to word this so that
> the requirement is only on the transmitter. (i.e. the transmitter
MUST)
>=20
> Barry Reinhold
> Lamprey Networks
> bbr@lampreynetworks.com
> (603) 868-8411
>=20
>=20
>=20
>=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 exim@www1.ietf.org  Thu Nov 13 20:53:02 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04294
	for <rddp-archive@odin.ietf.org>; Thu, 13 Nov 2003 20:53:02 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKT8d-0002bc-VI
	for rddp-archive@odin.ietf.org; Thu, 13 Nov 2003 20:52:44 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE1qhFA010010
	for rddp-archive@odin.ietf.org; Thu, 13 Nov 2003 20:52:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKT8d-0002bN-Qt
	for rddp-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 20:52:43 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04281
	for <rddp-web-archive@ietf.org>; Thu, 13 Nov 2003 20:52:31 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKT8b-0002N4-00
	for rddp-web-archive@ietf.org; Thu, 13 Nov 2003 20:52:41 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKT8a-0002N1-00
	for rddp-web-archive@ietf.org; Thu, 13 Nov 2003 20:52:40 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKT7y-0002WQ-6u; Thu, 13 Nov 2003 20:52:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKT7u-0002VK-5D
	for rddp@optimus.ietf.org; Thu, 13 Nov 2003 20:51:58 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04229
	for <rddp@ietf.org>; Thu, 13 Nov 2003 20:51:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKT7r-0002Lq-00
	for rddp@ietf.org; Thu, 13 Nov 2003 20:51:55 -0500
Received: from thebe.your-site.com ([140.186.45.26])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKT7q-0002LK-00
	for rddp@ietf.org; Thu, 13 Nov 2003 20:51:54 -0500
Received: from [192.168.0.2] (64-144-5-25.client.dsl.net [64.144.5.25])
	by thebe.your-site.com (Postfix) with ESMTP
	id CE795244B68; Thu, 13 Nov 2003 20:52:05 -0500 (EST)
In-Reply-To: <002c01c3aa32$241e2d30$467fa8c0@i8600>
References: <002c01c3aa32$241e2d30$467fa8c0@i8600>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <0E1430D8-1645-11D8-AAEF-003065D48EE0@asomi.com>
Content-Transfer-Encoding: 7bit
Cc: "RDDP" <rddp@ietf.org>
From: Caitlin Bestler <cait@asomi.com>
Subject: Re: [rddp] Transmission of RsvdULP in each segment or an RDDP message
Date: Thu, 13 Nov 2003 19:51:25 -0600
To: "Barry Reinhold" <bbr@lampreynetworks.com>
X-Mailer: Apple Mail (2.606)
Content-Transfer-Encoding: 7bit
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Nov 13, 2003, at 4:04 PM, Barry Reinhold wrote:

Folks,
	I'm playing a bit a catch up here and may be exhuming old
bodies, but could someone motivate the rational behind this pp?

         The RsvdULP field is opaque to the DDP protocol and can be
         structured in any way by the ULP. At the Data Source, DDP
MUST
         set RsvdULP Field to the value specified by the ULP. It is
         transferred unmodified from the Data Source to the Data Sink.
         At the Data Sink, DDP MUST provide the RsvdULP field to the
ULP
         when the DDP Message is delivered. Each DDP Segment within a
         specific DDP Message MUST contain the same value for this
         field.

In particular I don't understand the motivation for the last
sentence.
- From a conformance point of view I have to test this statement for
both
the xmitter and receiver. For the receiver this would be done by
generating a DDP message with N DDP segments. I would then run N
trials
in which one of the N segments has a modified RsvdULP field in the
header. This would verify that the receiving DDP entity checked the
field (The receiver check has to be done given the MUST -- since MUST
is
only used for requirements that impact interoperability - this is an
implicit rule that the receiver checks or uses this -- otherwise it
doesn't impact interoperability). I'm sure people are not planning on
having their receiver code check this.

I think a better way to write this would be to have the receiver only
look at this field when the L bit is set. If the L bit is not set the
field should be ignored.



I suspect that everyone is planning on implementing it that way.

The difference is in the interpretation of what a MUST requirement
on the Sender means to the receiver.

	If the Sender MUST do X, then the Receiver MAY simply assume
	that it has done so.

	But it SHOULD NOT do so if this creates a security vulnerability.

In this case there is no security vulnerability, the receiver is
thoroughly not impacted by fields that it ignores. So the fact
that they MUST be the same frees the receiver to examine only the
one with the L bit set.

It also means that if some implementation came up with a way to do
speculative work base on an early field it could, knowing that the
final one will have the same value. (I can't think of anything right
now, but in theory you could).


- --
Caitlin Bestler - cait@asomi.com - http://asomi.com/
http://asomi.com/CaitlinBestlerPublicPgpKey.html

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBP7Qm/LY6y5WqUdvJEQI86ACfbvG4WZ/Okg5mNYpuIglGRtJv9EwAoMro
DlxZzWPhW2J/t2RC86trlUl2
=hu0c
-----END PGP SIGNATURE-----


_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp



From exim@www1.ietf.org  Mon Nov 17 10:02:24 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13468
	for <rddp-archive@odin.ietf.org>; Mon, 17 Nov 2003 10:02:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALktB-0001gF-N2
	for rddp-archive@odin.ietf.org; Mon, 17 Nov 2003 10:02:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHF25ib006454
	for rddp-archive@odin.ietf.org; Mon, 17 Nov 2003 10:02:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALktB-0001g0-Hk
	for rddp-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 10:02:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13448
	for <rddp-web-archive@ietf.org>; Mon, 17 Nov 2003 10:01:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALkt9-0007RS-00
	for rddp-web-archive@ietf.org; Mon, 17 Nov 2003 10:02:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALkt9-0007RN-00
	for rddp-web-archive@ietf.org; Mon, 17 Nov 2003 10:02:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALkt7-0001fX-Ce; Mon, 17 Nov 2003 10:02:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALksT-0001ep-IW
	for rddp@optimus.ietf.org; Mon, 17 Nov 2003 10:01:21 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13418
	for <rddp@ietf.org>; Mon, 17 Nov 2003 10:01:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALksR-0007Qs-00
	for rddp@ietf.org; Mon, 17 Nov 2003 10:01:19 -0500
Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALksQ-0007Qn-00
	for rddp@ietf.org; Mon, 17 Nov 2003 10:01:19 -0500
Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP
  (SMTPD32-7.00) id A3C6307F0128; Mon, 17 Nov 2003 10:05:42 -0500
From: "Barry Reinhold" <bbr@lampreynetworks.com>
To: "RDDP" <rddp@ietf.org>
Date: Mon, 17 Nov 2003 10:01:11 -0500
Message-ID: <000701c3ad1b$a44407f0$467fa8c0@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
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [rddp] Clarification on intent of requirement
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Clause 5 item 4 of draft-ietf-rddp-ddp-01 states:

   4.  The LLP MUST preserve DDP Segment and Message boundaries at the 
       Data Sink. 

For the LLP to preserve the DDP segment boundary I would expect that the
LLP (MPA/SCTP) would, in some virtual API, provides an indication that
the DDP segment is available (i.e. the full DDP segment is available in
some buffer and is without error). Given an API this could be tested.

I am not clear on what the LLP is supposed to do with a DDP message
boundary. A DDP message boundary is defined by a bit in a DDP header and
the semantics associated with processing a DDP message do not seem to be
appropriate for the LLP. In what way is the LLP supposed to "preserve" a
DDP message? 



Barry Reinhold
Lamprey Networks
bbr@lampreynetworks.com
(603) 868-8411
 



_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp



From exim@www1.ietf.org  Mon Nov 17 10:27:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15592
	for <rddp-archive@odin.ietf.org>; Mon, 17 Nov 2003 10:27:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALlHL-0003jr-A7
	for rddp-archive@odin.ietf.org; Mon, 17 Nov 2003 10:27:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHFR37d014363
	for rddp-archive@odin.ietf.org; Mon, 17 Nov 2003 10:27:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALlHK-0003jY-Le
	for rddp-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 10:27:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15546
	for <rddp-web-archive@ietf.org>; Mon, 17 Nov 2003 10:26:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALlHI-0007n2-00
	for rddp-web-archive@ietf.org; Mon, 17 Nov 2003 10:27:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALlHH-0007mz-00
	for rddp-web-archive@ietf.org; Mon, 17 Nov 2003 10:27:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALlHJ-0003ij-Eh; Mon, 17 Nov 2003 10:27:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALlGo-0003ZM-SK
	for rddp@optimus.ietf.org; Mon, 17 Nov 2003 10:26:30 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15523
	for <rddp@ietf.org>; Mon, 17 Nov 2003 10:26:17 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALlGm-0007mG-00
	for rddp@ietf.org; Mon, 17 Nov 2003 10:26:28 -0500
Received: from thebe.your-site.com ([140.186.45.26])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALlGm-0007lD-00
	for rddp@ietf.org; Mon, 17 Nov 2003 10:26:28 -0500
Received: from [192.168.0.2] (64-144-5-25.client.dsl.net [64.144.5.25])
	by thebe.your-site.com (Postfix) with ESMTP
	id 2E4442450A4; Mon, 17 Nov 2003 10:26:36 -0500 (EST)
In-Reply-To: <000701c3ad1b$a44407f0$467fa8c0@i8600>
References: <000701c3ad1b$a44407f0$467fa8c0@i8600>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <5AD21CC6-1912-11D8-AEFC-003065D48EE0@asomi.com>
Content-Transfer-Encoding: 7bit
Cc: "RDDP" <rddp@ietf.org>
From: Caitlin Bestler <cait@asomi.com>
Subject: Re: [rddp] Clarification on intent of requirement
Date: Mon, 17 Nov 2003 09:26:03 -0600
To: "Barry Reinhold" <bbr@lampreynetworks.com>
X-Mailer: Apple Mail (2.606)
Content-Transfer-Encoding: 7bit
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


On Nov 17, 2003, at 9:01 AM, Barry Reinhold wrote:

> Clause 5 item 4 of draft-ietf-rddp-ddp-01 states:
>
>    4.  The LLP MUST preserve DDP Segment and Message boundaries at the
>        Data Sink.
>
> For the LLP to preserve the DDP segment boundary I would expect that 
> the
> LLP (MPA/SCTP) would, in some virtual API, provides an indication that
> the DDP segment is available (i.e. the full DDP segment is available in
> some buffer and is without error). Given an API this could be tested.
>
> I am not clear on what the LLP is supposed to do with a DDP message
> boundary. A DDP message boundary is defined by a bit in a DDP header 
> and
> the semantics associated with processing a DDP message do not seem to 
> be
> appropriate for the LLP. In what way is the LLP supposed to "preserve" 
> a
> DDP message?
>
>

The requirement that the LLP "preserve Message boundaries" is perhaps
misleading, because it is merely preserving the portion of the segment
that indicates it is a message boundary. But the LLP is preserving the
entire message, with no understanding of its internal structure, so of
course it preserve whatever portion is responsible for marking message
boundaries. If the draft authors want to clean the language up, fine,
but it certainly is not an error as written.

Preserving Segment boundaries is more important, and what I understood
the primary purpose of the clause to be. It is a re-affirmation that
the service offered by the LLP is reliable delivery of DDP Segments,
not byte streams.

Also, keep in mind that the virtual API between the LLP and DDP is
allowed to have *two* methods: one for placement and a second for
completion. At the time LLP completion is reported, the information
on where the DDP Segment boundaries were must not have been lost.
In particular the fact that TCP has acked a *portion* of a DDP Segment
has no meaning to the DDP layer. It is not LLP completed until the
entire segment has been LLP acked.

For the SCTP mapping, each DDP Segment is a single-chunk SCTP User
Message, so there are no potential conflicts.


_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp



From exim@www1.ietf.org  Mon Nov 17 13:24:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27010
	for <rddp-archive@odin.ietf.org>; Mon, 17 Nov 2003 13:24:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALo2d-0005Et-PQ
	for rddp-archive@odin.ietf.org; Mon, 17 Nov 2003 13:24:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHIO3tk020133
	for rddp-archive@odin.ietf.org; Mon, 17 Nov 2003 13:24:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALo2d-0005Ee-LS
	for rddp-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 13:24:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26999
	for <rddp-web-archive@ietf.org>; Mon, 17 Nov 2003 13:23:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALo2b-0003pF-00
	for rddp-web-archive@ietf.org; Mon, 17 Nov 2003 13:24:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALo2b-0003pC-00
	for rddp-web-archive@ietf.org; Mon, 17 Nov 2003 13:24:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALo2b-0005E7-Be; Mon, 17 Nov 2003 13:24:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALo1p-0005BA-4k
	for rddp@optimus.ietf.org; Mon, 17 Nov 2003 13:23:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26964
	for <rddp@ietf.org>; Mon, 17 Nov 2003 13:22:58 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALo1m-0003oN-00
	for rddp@ietf.org; Mon, 17 Nov 2003 13:23:10 -0500
Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALo1m-0003oC-00
	for rddp@ietf.org; Mon, 17 Nov 2003 13:23:10 -0500
Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP
  (SMTPD32-7.00) id A309372C00B8; Mon, 17 Nov 2003 13:27:21 -0500
From: "Barry Reinhold" <bbr@lampreynetworks.com>
To: "RDDP" <rddp@ietf.org>
Date: Mon, 17 Nov 2003 13:22:50 -0500
Message-ID: <000b01c3ad37$cf6e1350$467fa8c0@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
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [rddp] Clause 3 comments for draft-ietf-rddp-ddp-01
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Below are comments on clause 3 of draft-ietf-rddp-ddp-01

There are 10 Editorial comments here all dealing with editorial nits.
This is only of interest to the editor(s).


Comments are given in the following form:

Number, type, significance, reference
Comment

CLAUSE 3

1, Editorial, Low 3 1st PP, page 3

Is: Direct Data Placement Protocol (DDP) enables an Upper Layer Protocol

   (ULP) to send data to a Data Sink without requiring the Data Sink to 
   Place the data in an intermediate buffer - thus when the data 
   arrives at the Data Sink, the network interface can Place the data 
   directly into the ULP's buffer. This can enable the Data Sink to 
   consume substantially less memory bandwidth than a buffered model 
   because the Data Sink is not required to move the data from the 
   intermediate buffer to the final destination. Additionally, this can 
   also enable the network protocol to consume substantially fewer CPU 
   cycles than if the CPU was used to move the data, and removes the 
   bandwidth limitation of only being able to move data as fast as the 
   CPU can copy the data. 

Suggest: Direct Data Placement Protocol (DDP) enables an Upper Layer
Protocol 
   (ULP) to send data to a data sink without requiring the data sink to 
   place the data in an intermediate buffer - thus when the data 
   arrives at the data sink, the network interface can place the data 
   directly into the ULP's buffer. This can enable the data sink to 
   consume substantially less memory bandwidth than a buffered model 
   because the data sink is not required to move the data from the 
   intermediate buffer to the final destination. Additionally, this can 
   also enable the network protocol to consume substantially fewer CPU 
   cycles than if the CPU was used to move the data, and removes the 
   bandwidth limitation of only being able to move data as fast as the 
   CPU can copy the data. 
Changes: Removed capitalization on "data sink" and "place"

2, Editorial, Low 3.1 1st bullet page 4

Is:     
* Provide a buffer model that enables the Local Peer to Advertise 
        a named buffer (i.e. a Tag for a buffer) to the Remote Peer, 
        such that across the network the Remote Peer can Place data 
        into the buffer at Remote Peer specified locations. This is 
        referred to as the Tagged Buffer Model. 

Suggest:     
* Provide a buffer model that enables the local peer to advertise 
        a named buffer (i.e. a tag for a buffer) to the remote peer, 
        such that across the network the remote peer can place data 
        into the buffer at remote peer specified locations. This is 
        referred to as the tagged buffer model. 
Changes: removed capitalization of "local peer", "advertise", "remote
peer", tagged buffer model, and "place".

3, Editorial, Low 3.1, 2nd bullet page 4

Is: 
     * Provide a second receive buffer model which preserves ULP 
        message boundaries from the Remote Peer and keeps the Local 
        Peer's buffers anonymous (i.e. Untagged). This is referred to 
        as the Untagged Buffer Model. 
Suggest:
     * Provide a second receive buffer model which preserves ULP 
        message boundaries from the remote peer and keeps the local 
        peer's buffers anonymous (i.e. untagged). This is referred to 
        as the untagged buffer model.
Changes: removed capitalization

4, Editorial, Low 3.1, 3rd bullet page 4

Is:
     * Provide reliable, in-order Delivery semantics for both Tagged 
        and Untagged Buffer Models.  
Suggest:
     * Provide reliable, in-order delivery semantics for both Tagged 
        and untagged buffer models.
Changes: Capitalization

5, Editorial, Low 3.1, 5th bullet page 4

Is:
     * Enable the ULP buffer to be used as a reassembly buffer, 
        without a need for a copy, even if incoming DDP Segments arrive 
        out of order. This requires the protocol to separate Data 
        Placement of ULP Payload contained in an incoming DDP Segment 
        from Data Delivery of completed ULP Messages. 
Suggest:
     * Enable the ULP buffer to be used as a reassembly buffer, 
        without a need for a copy, even if incoming DDP segments arrive 
        out of order. This requires the protocol to separate data 
        placement of ULP payload contained in an incoming DDP segment 
        from data delivery of completed ULP messages.
Change: Capitalization

6 Editorial, Low 3.1 6th bullet page 4

Is:
     * If the LLP supports multiple LLP streams within a LLP 
        Connection, provide the above capabilities independently on 
        each LLP stream and enable the capability to be exported on a 
        per LLP stream basis to the ULP. 

Suggest:
     * If the LLP supports multiple LLP streams within a LLP 
        connection, provide the above capabilities independently on 
        each LLP stream and enable the capability to be exported on a 
        per LLP stream basis to the ULP.
Change: Capitalization

7 Editorial, Low 3.2 1st three pps page 4

Is:
DDP supports two basic data transfer models - a Tagged Buffer data 
   transfer model and an Untagged Buffer data transfer model.  

   The Tagged Buffer data transfer model requires the Data Sink to send 
   the Data Source an identifier for the ULP buffer, referred to as a 
   Steering Tag (STag). The STag is transferred to the Data Source 
   using a ULP defined method. Once the Data Source ULP has an STag for 
   a destination ULP buffer, it can request that DDP send the ULP data 
   to the destination ULP buffer by specifying the STag to DDP. Note 
   that the Tagged Buffer does not have to be filled starting at the 
   beginning of the ULP buffer. The ULP Data Source can provide an 
   arbitrary offset into the ULP buffer.  

   The Untagged Buffer data transfer model enables data transfer to 
   occur without requiring the Data Sink to Advertise a ULP Buffer to 
   the Data Source. The Data Sink can queue up a series of receive ULP 
   buffers. An Untagged DDP Message from the Data Source consumes an 
   Untagged Buffer at the Data Sink. Because DDP is message oriented, 
   even if the Data Source sends a DDP Message payload smaller than the 
   receive ULP buffer, the partially filled receive ULP buffer is 
   Delivered to the ULP anyway. If the Data Source sends a DDP Message 
   payload larger than the receive ULP buffer, it results in an error.  

   There are several key differences between the Tagged and Untagged 
   Buffer Model: 
 
Suggest:
DDP supports two basic data transfer models - a tagged buffer data 
   transfer model and an untagged buffer data transfer model.  

   The tagged buffer data transfer model requires the data sink to send 
   the data source an identifier for the ULP buffer, referred to as a 
   Steering Tag (STag). The STag is transferred to the data source 
   using a ULP defined method. Once the data source ULP has an STag for 
   a destination ULP buffer, it can request that DDP send the ULP data 
   to the destination ULP buffer by specifying the STag to DDP. Note 
   that the tagged buffer does not have to be filled starting at the 
   beginning of the ULP buffer. The ULP data source can provide an 
   arbitrary offset into the ULP buffer.  

   The untagged buffer data transfer model enables data transfer to 
   occur without requiring the data sink to advertise a ULP buffer to 
   the data source. The data sink can queue up a series of receive ULP 
   buffers. An untagged DDP message from the data source consumes an 
   untagged buffer at the data sink. Because DDP is message oriented, 
   even if the data source sends a DDP message payload smaller than the 
   receive ULP buffer, the partially filled receive ULP buffer is 
   delivered to the ULP anyway. If the data source sends a DDP message 
   payload larger than the receive ULP buffer, it results in an error.  

   There are several key differences between the tagged and untagged 
   buffer model: 

Changes: Capitalization

8 Editorial, Low, 3.2, bullets on page 5

Is:
     * For the Tagged Buffer Model, the Data Source specifies which 
        received Tagged Buffer will be used for a specific Tagged DDP 
        Message (sender-based ULP buffer management). For the Untagged 
        Buffer Model, the Data Sink specifies the order in which 
        Untagged Buffers will be consumed as Untagged DDP Messages are 
        received (receiver-based ULP buffer management). 

     * For the Tagged Buffer Model, the ULP at the Data Sink must 
        Advertise the ULP buffer to the Data Source through a ULP 
        specific mechanism before data transfer can occur. For the 
        Untagged Buffer Model, data transfer can occur without an end-
        to-end explicit ULP buffer Advertisement. Note, however, that 
        the ULP needs to address flow control issues. 

     * For the Tagged Buffer Model, a DDP Message can start at an 
        arbitrary offset within the Tagged Buffer. For the Untagged 
        Buffer Model, a DDP Message can only start at offset 0. 

     * The Tagged Buffer Model allows multiple DDP Messages targeted 
        to a Tagged Buffer with a single ULP buffer Advertisement. The 
        Untagged Buffer Model requires associating a receive ULP buffer 
        for each DDP Message targeted to an Untagged Buffer.  
Suggest:
     * For the tagged buffer model, the data source specifies which 
        received tagged buffer will be used for a specific tagged DDP 
        message (sender-based ULP buffer management). For the untagged 
        buffer model, the data sink specifies the order in which 
        untagged buffers will be consumed as untagged DDP messages are 
        received (receiver-based ULP buffer management). 

     * For the tagged buffer model, the ULP at the data sink must 
        advertise the ULP buffer to the data source through a ULP 
        specific mechanism before data transfer can occur. For the 
        untagged buffer model, data transfer can occur without an end-
        to-end explicit ULP buffer advertisement. Note, however, that 
        the ULP needs to address flow control issues. 

     * For the tagged buffer model, a DDP message can start at an 
        arbitrary offset within the tagged buffer. For the untagged 
        buffer model, a DDP message can only start at offset 0. 

     * The tagged buffer model allows multiple DDP messages targeted 
        to a tagged buffer with a single ULP buffer advertisement. The 
        untagged buffer model requires associating a receive ULP buffer 
        for each DDP message targeted to an untagged buffer. 
Change: Capitalization

9 Editorial, Low 3.2, text following bullets to end of clause

Is:
Either data transfer model Places a ULP Message into a DDP Message. 
   Each DDP Message is then sliced into DDP Segments that are intended  
 
shah, et. al.             Expires April 2004                         5 
 
Internet-Draft        DDP Protocol Specification        October 2003 
 
   to fit within a lower-layer-protocol's (LLP) Maximum Upper Layer 
   Protocol Data Unit (MULPDU). Thus the ULP can post arbitrary size 
   ULP Messages, containing up to 2^32 - 1 octets of ULP Payload, and 
   DDP slices the ULP message into DDP Segments which are reassembled 
   transparently at the Data Sink.  

   DDP provides in-order Delivery for the ULP. However, DDP 
   differentiates between Data Delivery and Data Placement. DDP 
   provides enough information in each DDP Segment to allow the ULP 
   Payload in each inbound DDP Segment payloads to be directly Placed 
   into the correct ULP Buffer, even when the DDP Segments arrive out-
   of-order. Thus, DDP enables the reassembly of ULP Payload contained 
   in DDP Segments of a DDP Message into a ULP Message to occur within 
   the ULP Buffer, therefore eliminating the traditional copy out of 
   the reassembly buffer into the ULP Buffer. 

   A DDP Message's payload is Delivered to the ULP when: 

     * all DDP Segments of a DDP Message have been completely received 
        and the payload of the DDP Message has been Placed into the 
        associated ULP Buffer, 

     * all prior DDP Messages have been Placed, and 

     * all prior DDP Message Deliveries have been performed. 

   The LLP under DDP may support a single LLP stream of data per 
   connection (e.g. TCP) or multiple LLP streams of data per connection 
   (e.g. SCTP). But in either case, DDP is specified such that each DDP 
   Stream is independent and maps to a single LLP stream. Within a 
   specific DDP Stream, the LLP Stream is required to provide in-order, 
   reliable Delivery. Note that DDP has no ordering guarantees between 
   DDP Streams. 

   A DDP protocol could potentially run over reliable Delivery LLPs or 
   unreliable Delivery LLPs. This specification requires reliable, in 
   order Delivery LLPs. 
Suggest:
Either data transfer model places a ULP message into a DDP message. 
   Each DDP message is then sliced into DDP segments that are intended  
 
shah, et. al.             Expires April 2004                         5 
 
Internet-Draft        DDP Protocol Specification        October 2003 
 
   to fit within a lower-layer-protocol's (LLP) Maximum Upper Layer 
   Protocol Data Unit (MULPDU). Thus the ULP can post arbitrary size 
   ULP messages, containing up to 2^32 - 1 octets of ULP payload, and 
   DDP slices the ULP message into DDP segments which are reassembled 
   transparently at the data sink.  

   DDP provides in-order delivery for the ULP. However, DDP 
   differentiates between data delivery and data placement. DDP 
   provides enough information in each DDP Segment to allow the ULP 
   payload in each inbound DDP segment payloads to be directly placed 
   into the correct ULP Buffer, even when the DDP Segments arrive out-
   of-order. Thus, DDP enables the reassembly of ULP payload contained 
   in DDP segments of a DDP message into a ULP message to occur within 
   the ULP buffer, therefore eliminating the traditional copy out of 
   the reassembly buffer into the ULP buffer. 

   A DDP message's payload is delivered to the ULP when: 

     * all DDP segments of a DDP message have been completely received 
        and the payload of the DDP message has been placed into the 
        associated ULP buffer, 

     * all prior DDP messages have been placed, and 

     * all prior DDP message deliveries have been performed. 

   The LLP under DDP may support a single LLP stream of data per 
   connection (e.g. TCP) or multiple LLP streams of data per connection 
   (e.g. SCTP). But in either case, DDP is specified such that each DDP 
   stream is independent and maps to a single LLP stream. Within a 
   specific DDP stream, the LLP stream is required to provide in-order, 
   reliable delivery. Note that DDP has no ordering guarantees between 
   DDP streams. 

   A DDP protocol could potentially run over reliable delivery LLPs or 
   unreliable delivery LLPs. This specification requires reliable, in 
   order delivery LLPs.
Changes: Capitalization

10 Editorial Low 3.3 text before figure 1

Is:
   DDP enables direct data Placement capability for any ULP, but it has 
   been specifically designed to work well with RDMAP (see [RDMA]), and 
   is part of the iWARP protocol suite.  
Suggest:
   DDP enables direct data placement capability for any ULP, but it has 
   been specifically designed to work well with RDMAP (see [RDMA]), and 
   is part of the iWARP protocol suite. 
Change: Capitalization of "placement" 
 

Barry Reinhold
Lamprey Networks
bbr@lampreynetworks.com
(603) 868-8411
 



_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp



From exim@www1.ietf.org  Mon Nov 17 13:34:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27273
	for <rddp-archive@odin.ietf.org>; Mon, 17 Nov 2003 13:34:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALoCI-0005g7-QU
	for rddp-archive@odin.ietf.org; Mon, 17 Nov 2003 13:34:02 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHIY2vO021821
	for rddp-archive@odin.ietf.org; Mon, 17 Nov 2003 13:34:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALoCI-0005fs-MX
	for rddp-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 13:34:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27251
	for <rddp-web-archive@ietf.org>; Mon, 17 Nov 2003 13:33:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALoCG-0003w7-00
	for rddp-web-archive@ietf.org; Mon, 17 Nov 2003 13:34:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALoCG-0003w4-00
	for rddp-web-archive@ietf.org; Mon, 17 Nov 2003 13:34:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALoCH-0005fK-Ks; Mon, 17 Nov 2003 13:34:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALoBu-0005ei-VV
	for rddp@optimus.ietf.org; Mon, 17 Nov 2003 13:33:38 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27241
	for <rddp@ietf.org>; Mon, 17 Nov 2003 13:33:26 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALoBs-0003vq-00
	for rddp@ietf.org; Mon, 17 Nov 2003 13:33:36 -0500
Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALoBs-0003vm-00
	for rddp@ietf.org; Mon, 17 Nov 2003 13:33:36 -0500
Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP
  (SMTPD32-7.00) id A58F32F200C4; Mon, 17 Nov 2003 13:38:07 -0500
From: "Barry Reinhold" <bbr@lampreynetworks.com>
To: "RDDP" <rddp@ietf.org>
Date: Mon, 17 Nov 2003 13:33:37 -0500
Message-ID: <000c01c3ad39$51141e80$467fa8c0@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
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [rddp] Clause 4 comments to draft-ietf-rddp-ddp-01
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

CLAUSE 4

Below are comments on clause 4. There are 32 editorial comments, most
are nits, but there are some rewordings that are significantly
different. Most of the rewording was made in an effort to improve the
clarity of the concept being defined. None of the rewording is believed
to be a technical change.


1, Editorial, Low, 4.1 under Advertisement

Is: the act

Suggest: The act

Change is: Capitalize "the"

2, Editorial, low, 4.1 under Data Delivery

Is: Delivery is defined as the process of informing the ULP or consumer
that a particular Message is available for use.

Suggest: Delivery is defined as the process of informing the ULP or
consumer that a particular message is available for use.

Change: capitalization of "message" removed

3, Editorial, low, 4.1 under Data Delivery

Is: This is specifically different from "Placement", which may generally
occur in any order, while the order of "Delivery" is strictly defined.

Suggest: Delivery is distinct from "placement". Placement of data into
ULP buffers may occur in any order, whereas the order of message
"delivery" to the ULP is strictly defined.

Change: Reword

4, Editorial, low, 4.1 under Data Sink

Is: Note that the Data Sink can be required to both send and receive
RDMA/DDP Messages to transfer a data payload.

Suggest: Note that the Data Sink can be required to both send and
receive RDMA/DDP messages to transfer a data payload.

Change: capitalization of "message" removed

5, Editorial, low, 4.1 under Data Sink

Is: Note that the Data Source can be required to both send and receive
RDMA/DDP Messages to transfer a data payload.

Suggest: Note that the Data Source can be required to both send and
receive RDMA/DDP messages to transfer a data payload.

Change: capitalization of "message" removed

6, Editorial, low, 4.1 under Node

Is: A computing device attached to one or more links of network.

Suggest: A computing device attached to a network by one or more links.

Change: Reword

7. Editorial, low, 4.1 under ULP

Is: The ULP for RDMA/DDP is expected to be an OS, Application,
adaptation layer, or proprietary device.

Suggest: The ULP for RDMA/DDP is expected to be an OS, application,
adaptation layer, or proprietary device.

Change: capitalization of application removed

8. Editorial, low 4.1 under ULP Message

Is: the ULP data that is handed to a specific protocol layer for
transmission.

Suggest: The ULP data that is handed to a specific protocol layer for
transmission.

Change: Capitalize the first word in the sentence

9. Editorial, low 4.1, 4.2

Consistency of sections - The current draft has three sub sections,
General, LLP, and DDP. Given that framework it appears that there should
be a sub section for ULP containing (ULP, ULP message, ULP payload, ULP
buffer, and ULP message length). However, the way a glossary is used is
to quickly identify the meaning of a term. Given the size of the
glossary a single level alphabetical organization is probably better.

Suggest: Removing sub sections in the glossary.

10. Editorial, medium, 4.2 & 4.3 under LLP Connection and LLP Stream,
also relates to 4.3 DDP Stream.

The definitions of stream and connection could be more precise.
Currently defined are DDP stream, LLP stream, and LLP connection. 

Within the draft document connection is used five times without a LLP
qualification (clause 3.2 page 6, clause 4.1 under local peer, remote
peer, and LLP stream, clause 10.4), stream is used four times (8.2, 9.1
item 1, 9.1 item 1 under non-zero case, and 10.4 item 3) without
qualification.

Suggest: Defining DDP stream, and DDP connection in terms of concepts
significant to DDP. Define LLP connection and LLP stream by reference to
LLP protocol specifications. Possible wording below:

DDP stream - A logical channel between a local peer and a remote peer in
which the ordering of a sequence of DDP messages is maintained. There is
no guarantee of message ordering when a sequence of DDP messages is sent
over more then one stream.

DDP connection - An association between two DDP peers that provides a
context for DDP streams. DDP streams can not exist outside the context
of a DDP connection. If supported by the LLP, more then one DDP stream
may exist within a single DDP connection as in SCTP. 

LLP connection - A connection as defined by the lower layer protocol.
See [SCTP], [TCP].

LLP stream - The logical channel provided by the LLP that allows the
ordered delivery of DDP messages between DDP peers. For SCTP the LLP
stream is the SCTP stream (see [SCTP]). For TCP the ordered delivery
service is provided by the TCP connection (see [TCP]). Note that TCP
supports no more than one DDP stream per TCP connection.

11. Editorial, medium, 4.2 under ULPDU

Is: Upper Layer Protocol Data Unit.  The data record defined by 
       the layer above MPA.

Suggest: Upper Layer Protocol Data Unit.  The data record defined by 
       the layer above DDP.

Change: Replaced MPA with DDP.

12. Editorial, low, 4.3 under Data Placement

Is: Placement (Placement, Placed, Places) - For DDP, this term is 
       specifically used to indicate the process of writing to a data 
       buffer by a DDP implementation.  DDP Segments carry Placement 
       information, which may be used by the receiving DDP 
       implementation to perform Data Placement of the DDP Segment ULP 
       Payload. See "Data Delivery".

Suggest: Placement (Placement, Placed, Places) - The process of writing
the ULP payload of a DDP segment to the data buffer specified in the
header of the DDP segment. Placement and delivery have specific and
distinct meaning in DDP. See "Data Delivery" and "Direct Data
Placement".

Change: Reword and simplify, reference Direct Data Placement for
additional details.

13. Editorial, low, 4.3 under DDP Control Field

Is: a fixed 8-bit field in the DDP Header.

Suggested: A fixed 8-bit field in the DDP header.

Change: Capitalize "a", remove capitalization of header

14. Editorial, low, 4.3 under DDP Header

Is: The header present in all DDP Segments. The DDP Header 
       contains control and Placement fields that are used to define 
       the final Placement location for the ULP Payload carried in a 
       DDP Segment.

Suggest: The header present in all DDP segments. The DDP header contains
control and placement information. (See clause 6)

Change: Reword and added reference.

15. Editorial, low, 4.3 under DDP Message

 Is: A ULP defined unit of data interchange, which is 
       subdivided into one or more DDP Segments. This segmentation may 
       occur for a variety of reasons, including segmentation to 
       respect the maximum segment size of the underlying transport 
       protocol.

Suggest: A ULP defined unit of data interchange, which is 
       subdivided into one or more DDP segments. This segmentation may 
       occur for a variety of reasons, including segmentation to 
       respect the maximum segment size of the underlying transport 
       protocol.

Change: Changed capitalization of DDP Segments... (nice definition BTW)

16. Editorial, low 4.3 under DDP Segment

Is: The smallest unit of data transfer for the DDP 
       protocol. It includes a DDP Header and ULP Payload (if present). 
       A DDP Segment should be sized to fit within the Lower Layer 
       Protocol MULPDU.

Suggest: The smallest unit of data transfer for the DDP 
       protocol. It includes a DDP header and ULP payload (if present). 
       A DDP segment should be sized to fit within the lower layer 
       protocol MULPDU.

Change: Capitalization

17. Editorial, low 4.3 under Direct Data Placement

Is: A mechanism whereby ULP data contained 
       within DDP Segments may be Placed directly into its final 
       destination in memory without processing of the ULP. This may 
       occur even when the DDP Segments arrive out of order. Out of 
       order Placement support may require the Data Sink to implement 
       the LLP and DDP as one functional block.

Suggest: The placement of the ULP payload in a DDP segment into its
final memory location without processing by the ULP. This may occur even
when the DDP Segments arrive out of order. Out of order placement
support may require the data sink to implement the LLP and DDP as one
functional block.

Change: Reword and capitalization

18. Editorial, medium 4.3 under Direct Data Placement Protocol

Is: Also, a wire protocol that 
       supports Direct Data Placement by associating explicit memory 
       buffer placement information with the LLP payload units.

Suggest: A wire protocol that enables direct data placement by
associating placement information with the ULP payload units. 

Change: Wording, replaced LLP with ULP.

19. Editorial, low 4.3 under Message Offset

Is: For the DDP Untagged Buffer Model, specifies 
       the offset, in octets, from the start of a DDP Message.

Suggest: The offset, in octets, from the start of a DDP message. Used
with the untagged buffer model.

Change: Wording, capitalization

20. Editorial, low 4.3 under Message Sequence Number (MSN)

Is: For the DDP Untagged Buffer Model, specifies a sequence number that
is increasing with each DDP Message.

Suggest:   A sequence number in the header of a DDP segment. Used with
untagged buffers. See clause 6.3.

Change: Replaced definition with reference to clause 6.3. The two did
not appear to be consistent; goal is to have a single definition in
spec.

21. Editorial, low 4.3 under Protection Domain

Is: A Mechanism used to associate a DDP Stream 
       and an STag. Under this mechanism, the use of an STag is valid 
       on a DDP Stream if the STag has the same Protection Domain 
       Identifier (PD ID) as the DDP Stream.

Suggest: A Mechanism used to associate a DDP stream 
       and an STag. Under this mechanism, the use of an STag is valid 
       on a DDP stream if the STag has the same protection domain 
       identifier (PD ID) as the DDP stream.

Change: Capitalization

22. Editorial, low 4.3 under QN

Is: For the DDP Untagged Buffer Model, identifies a destination Data
Sink queue for a DDP Segment.

Suggest: The destination data sink queue for a DDP segment. Used with
the untagged buffer model.

Change: wording, capitalization

23. Editorial, low 4.3 under Steering Tag

Is: An identifier of a Tagged Buffer on a Node, valid as 
       defined within a protocol specification.

Suggest: An identifier of a tagged buffer on a node, valid as 
       defined within a protocol specification. 

Change: capitalization

24. Editorial, low 4.3 under Tagged Buffer

Is: A buffer that is explicitly Advertised to the Remote 
       Peer through exchange of an STag, Target Offset, and length.  

Suggest: A buffer that is explicitly advertised to the remote 
       peer through exchange of an STag, target offset, and length.

Change: Capitalization

25. Editorial, medium, under Tagged Buffer Model

Is: A DDP data transfer model used to transfer Tagged Buffers from the
Local Peer to the Remote Peer. 

Suggest: A DDP data transfer model that allows the local peer to
advertise a named buffer. (See clause 3.1)

Change: Reword and added reference to more complete definition

26. Editorial, low 4.3 under Tagged DDP Message

Is:  A DDP Message that targets a Tagged Buffer. 

Suggest: A DDP message containing a Stag. Messages which contain Stags
use the tagged buffer model.

Change: Reworded to remove the word "targets"

27. Editorial, low, 4.3 under Tagged Offset

Is:  The offset within a Tagged Buffer on a Node.

Suggest: The offset, in octets, from the start of a tagged buffer. Used
with the tagged buffer model.
 
Change: wording to make consistent with MO. Capitalization

28. Editorial, low, 4.3 under ULP Buffer
 
Is: A buffer owned above the DDP Layer and advertised to 
       the DDP Layer either as a Tagged Buffer or an Untagged ULP 
       Buffer.

Suggest: A buffer owned above the DDP layer and advertised to 
       the DDP layer either as a tagged buffer or an untagged ULP 
       buffer.

Change: Capitalization

29. Editorial, low, 4.3 under ULP Message Length

Is: is the total length of the ULP Payload contained 
       in a DDP Message.

Suggest: The total length, in octets, of the ULP payload contained in a
DDP message.

Change: removed leading is, added octets, changed capitalization.

30. Editorial, low, 4.3 under Untagged Buffer

Is: A buffer that is not explicitly Advertised to the 
       Remote Peer.  

Suggest: A buffer that is not explicitly advertised to the remote peer.

Change: capitalization

31. Editorial, low, 4.3 under Untagged Buffer Model

Is: A DDP data transfer model used to transfer Untagged Buffers from the
Local Peer to the Remote Peer. 

Suggest: A DDP data transfer model that preserves ULP message boundaries
from the remote peer while keeping the local peers buffers anonymous.
(See clause 3.1)

32. Editorial, low, 4.3 under Untagged DDP Message

Is: A DDP Message that targets an Untagged 
       Buffer.

Suggest: A DDP message containing a queue number. Messages which contain
queue numbers use the untagged buffer model.

Change: reworded to remove the word "targets"



Barry Reinhold
Lamprey Networks
bbr@lampreynetworks.com
(603) 868-8411
 



_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp



From exim@www1.ietf.org  Mon Nov 17 13:39:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27402
	for <rddp-archive@odin.ietf.org>; Mon, 17 Nov 2003 13:39:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALoH8-00065F-5Z
	for rddp-archive@odin.ietf.org; Mon, 17 Nov 2003 13:39:02 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHId2XN023379
	for rddp-archive@odin.ietf.org; Mon, 17 Nov 2003 13:39:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALoH8-000650-1j
	for rddp-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 13:39:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27399
	for <rddp-web-archive@ietf.org>; Mon, 17 Nov 2003 13:38:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALoH5-0003yQ-00
	for rddp-web-archive@ietf.org; Mon, 17 Nov 2003 13:38:59 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALoH5-0003yN-00
	for rddp-web-archive@ietf.org; Mon, 17 Nov 2003 13:38:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALoH6-00064c-Sd; Mon, 17 Nov 2003 13:39:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALoH3-00064F-0L
	for rddp@optimus.ietf.org; Mon, 17 Nov 2003 13:38:57 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27396
	for <rddp@ietf.org>; Mon, 17 Nov 2003 13:38:44 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALoH0-0003yK-00
	for rddp@ietf.org; Mon, 17 Nov 2003 13:38:54 -0500
Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALoH0-0003yH-00
	for rddp@ietf.org; Mon, 17 Nov 2003 13:38:54 -0500
Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP
  (SMTPD32-7.00) id A6CE2FD50094; Mon, 17 Nov 2003 13:43:26 -0500
From: "Barry Reinhold" <bbr@lampreynetworks.com>
To: "RDDP" <rddp@ietf.org>
Date: Mon, 17 Nov 2003 13:38:56 -0500
Message-ID: <000d01c3ad3a$0eec9540$467fa8c0@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
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [rddp] comment clause 5 of draft-ietf-rddp-ddp-01
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


There are three comments on clause 5, (2 and 3) have technical content.

CLAUSE 5

NOTE: Given the effort associated with documenting the capitalization
issues and the frequency of capitalization issues these corrections are
no longer going to be documented. There may be some rule being applied
here that I am unaware of and if so this is a waste of time. 

It is suggested that the following terms have their capitalization
changed:
Message, Remote Peer, Local Peer, Untagged Buffer Model, Tagged Buffer
Model, Payload, Segment, Stream, Connection, Data Placement, Placement,
Delivery, Application.

1. Editorial, medium, 5 under item 4

Is:  4.  The LLP MUST preserve DDP Segment and Message boundaries at the

       Data Sink. 
Suggest:   4.  The LLP MUST preserve DDP Segment at the Data Sink.

Change: Removed reference to Message boundaries. Note that this is a
technical change if there is an actual requirement for the LLP to
understand DDP message boundaries. This change request is made as an
editorial request, believing that there is no requirement for the LLP to
understand message boundaries.

2. Technical, medium, 5 under item 8 and 10

Issue: The concept of an erroneous LLP stream is not defined or
referenced in this specification. It occurs in item 8 and 10 of this
clause. The semantics associated with marking a stream as an erroneous
stream needs further definition.

Is: 
If an LLP does not support teardown of a LLP stream independent 
       of other LLP streams and a DDP error occurs on a specific DDP 
       Stream, then the LLP MUST label the associated LLP stream as an 
       erroneous LLP stream and MUST NOT allow any further data 
       transfer on that LLP stream after DDP requests the associated 
       DDP Stream to be torn down. 

Suggest:

Add a definition for erroneous LLP stream in clause 4.2

"LLP Erroneous Stream - The LLP layer may mark a stream as being
erroneous to indicate to the DDP layer that the stream may no longer be
used for transmission of DDP segments."

Change item 8 to the following:

If an LLP does not support teardown of a LLP stream independent 
of other LLP streams and DDP request that the LLP stream be shutdown,
then LLP shall mark the stream as being an erroneous LLP stream. LLP
MUST NOT allow any further data transmission on a LLP stream marked as
erroneous.

No change is necessary to item 10

Suggestion 2:

Remove both references to erroneous streams. It is unclear to me that
DDP needs to understand the concept of an erroneous stream. When DDP
requests to tear down the stream due to a DDP error and the LLP must
defer from de-allocating the resources associated with the stream the
LLP should hide the "erroneous stream" state. In this case item 8
becomes:

If an LLP does not support teardown of a LLP stream independent of other
LLP streams it must present the LLP stream to DDP as being terminated.
The LLP entity MUST NOT allow any further data transfer on the LLP
stream. The LLP entity is not obligated to free up resources associated
with the LLP stream at the time of the teardown request.

Item 10 becomes:

   10. For a specific LLP connection, when all LLP streams are
gracefully           torn down the LLP connection MUST be torn down. 

3 Editorial, Low, 5 under clause 9

Is:

   9.  For a specific LLP Stream, the LLP MUST provide a mechanism to 
       indicate that the LLP Stream has been gracefully torn down. For 
       a specific LLP Connection, the LLP MUST provide a mechanism to 
       indicate that the LLP Connection has been gracefully torn down. 
       Note that if the LLP does not allow an LLP Stream to be torn 
       down independently of the LLP Connection, the above requirements 
       allow the LLP to notify DDP of both events at the same time. 
Suggest:
   9.  For a specific LLP stream, the LLP MUST provide a mechanism to 
       indicate that the LLP stream has been gracefully torn down.
       Note that if the LLP does not allow an LLP stream to be torn 
       down independently of the LLP connection, the above requirements 
       allow the LLP to notify DDP of both events at the same time.

Changes: Removed duplicated sentence and changed capitalization.

3 Editorial/technical, Low 5 under clause 11

Is:
The LLP MUST NOT pass a duplicate DDP Segment to the DDP Layer 
       after it has passed all the previous DDP Segments to the DDP 
       Layer and the associated ordering information for the previous 
       DDP Segments and the current DDP Segment. 
Suggest:
The LLP MUST NOT pass a duplicate DDP segment to the DDP layer.

Change: Removed qualifications. Do not understand the need for the
qualification. 


Barry Reinhold
Lamprey Networks
bbr@lampreynetworks.com
(603) 868-8411
 



_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp



From exim@www1.ietf.org  Mon Nov 17 16:16:23 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05505
	for <rddp-archive@odin.ietf.org>; Mon, 17 Nov 2003 16:16:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALqj6-0006V5-Sh
	for rddp-archive@odin.ietf.org; Mon, 17 Nov 2003 16:16:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHLG4Q5024981
	for rddp-archive@odin.ietf.org; Mon, 17 Nov 2003 16:16:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALqj6-0006Uq-PF
	for rddp-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 16:16:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05486
	for <rddp-web-archive@ietf.org>; Mon, 17 Nov 2003 16:15:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALqj4-0006JI-00
	for rddp-web-archive@ietf.org; Mon, 17 Nov 2003 16:16:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALqj4-0006JF-00
	for rddp-web-archive@ietf.org; Mon, 17 Nov 2003 16:16:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALqj3-0006UC-Nr; Mon, 17 Nov 2003 16:16:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALqiz-0006Tj-1r
	for rddp@optimus.ietf.org; Mon, 17 Nov 2003 16:15:57 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05463
	for <rddp@ietf.org>; Mon, 17 Nov 2003 16:15:44 -0500 (EST)
From: Black_David@emc.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALqix-0006In-00
	for rddp@ietf.org; Mon, 17 Nov 2003 16:15:55 -0500
Received: from [128.221.12.9] (helo=mxic2.corp.emc.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALqiw-0006HV-00
	for rddp@ietf.org; Mon, 17 Nov 2003 16:15:54 -0500
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <W58XFMAV>; Mon, 17 Nov 2003 16:15:22 -0500
Message-ID: <B459CE1AFFC52D4688B2A5B842CA35EA7A528B@corpmx14.corp.emc.com>
To: rddp@ietf.org
Date: Mon, 17 Nov 2003 16:15:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [rddp] DRAFT Minneapolis minutes
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>

Comments to me please.  Thanks, --David

RDDP WG Minneapolis meeting DRAFT minutes
Tuesday, November 11, 2003, 0900-1130
-----------------------------------------

Letters in [square brackets] are the first letter of
file name of presentation that goes with each agenda item.

-- Agenda Bashing and Administrivia [A]

No changes to agenda posted to mailing list.

-- Status of Drafts [B]

WG chair reviewed status of WG drafts.  See presentation
file for details.  Security draft is on critical path for
completion of DDP and RDMAP - due to current state of security
draft, WG milestones are likely to slip out by one IETF
meeting (about 3-4 months).

-- RDMA Applicability Statement [C]

In good shape.

-- DDP and RDMAP drafts [D]

Both are relatively stable, and have received minor updates
since Vienna.  The DDP draft had an implementers note added
to say that absence of a pre-allocated buffer for an inbound
untagged transfer does not need to immediately cause an error
that results in connection teardown - this was based on extensive
list discussion that concluded that implementations should be allowed
to keep a few "hidden" buffers to avoid (or delay) the consequences
of tearing down a connection.

WG chair plans an initial WG Last Call on these drafts during December,
BUT they cannot be forwarded to the ADs/IESG until the security draft
is complete, and work on that draft will probably cause additional
changes to the DDP and RDMAP drafts.

-- SCTP Mapping [no presentation]

In relatively good shape.  One important open issue is that the SCTP
mapping allows Active/Active startup, whereas the TCP mapping only
allows Active/Passive.  This needs to be consistent across both mappings,
and will be resolved on the list - see Action Items on this issue under
the next agenda item.

-- TCP Mapping [E]

A number of changes have been made since the Vienna meeting:
- The Start Key is now 2 separate frames, so that it differs in each
direction.
- Now using Initiator/Responder terms to designate roles in Active/Passive
	connection setup.  Discussion during the meeting suggested that
while
	Initiator is also used to describe SCSI, there are no better choices
	of terms readily available.
- "Private Data" support added.  Intention was to match SCTP support for
this.
- Added support for "Immediate Startup" (RDDP protocols start up immediately
	at start of TCP connection) and example.

+ Active/Active startup issue. 

Draft authors prefer not to support Active/Active because it is hard to get
right in a "dual stack" system that switches between an ordinary TCP (or
SCTP)
stack and an RDDP-enhanced one (e.g., in hardware).  This needs to be taken
to the list and resolved once for both transports (either both TCP and SCTP
support Active/Active, or neither does).  Action Items:

1) Draft authors to describe this problem including a sufficient functional
	model/description for a "dual stack" system to explain the
implementation
	difficulty.
2) WG chair to ask on list whether any ULPs that are (or can be) anticipated
	to use RDDP need, want, or would benefit from Active/Active startup.

In connection with 2), it was asked whether SDP (Sockets Direct Protocol)
could become an RDDP WG work item.  The answer is "yes, it could" - SDP
draft authors should consult with WG chair (who will consult with ADs as
appropriate) when the SDP draft appears.  SDP does not require Active/Active
startup, and sockets are Active/Passive (listener is passive).

Immediate startup (RDDP starts when TCP connection is established) 
favors Active/Passive due to connection handshake - initiator of
handshake should initiate RDDP setup on the established TCP connection.
SCTP uses adaption indications for this purpose.  Note that in this case,
the implementation has to "guess" what mode the connection will come up
in, and if that "guess" is wrong, the processing of data in the wrong
mode on the wrong "stack" in a "dual stack" system is likely to be
unrecoverable - recovery is via connection close and some sort of retry
(doing something different to avoid a repetition).  Needs to be discussed
on list as part of above "dual stack" discussion.

+ Minor issues (see slides)

- Is single bit difference in Initiator vs. Responder start frame formats
	ok?  Probably, but needs to be discussed on list.
- How to reference Verbs draft, since IETF may not publish it?
	Informative reference to RDMAC version of verbs draft as an
	**example** should be ok.  Verbs draft cannot be used to
	impose requirements on RDDP.

+ Startup round-trips

When ULP has exchanged data without RDDP and wants to switch into RDDP
mode, the resulting synchronization costs a round trip.  The "dual stack"
issue is a consideration here.

For immediate startup, the first message of the setup round trip can be
combined with the TCP ACK that concludes the TCP connection setup handshake,
thus reducing the cost to half a round trip, but that cost appears to be
necessary in order to support private data in a "dual stack" implementation.
Reducing this cost only helps if Active/Active setup is required, or first
data transfer is from TCP Listener.

An issue was raised on the list about the MPA private data mechanism,
but no one at the meeting could explain it.

--> Needless to say, the "dual stack" issues need significant discussion
on the list, as consideration of this class of implementation has had
significant influence on the design decisions.  As part of this, it will
be necessary to check whether SCTP's use of adaption indications changes
any of these issues.

-- Security Draft [F]

Comprehensive presentation (see slides) due to unfortunate conflict between
Vienna RDDP session (previous meeting) in which security was discussed
and saag (Security Area) meeting.

The sense of discussion in the room was that the partial trust taxonomy
and resulting matrix on slide 17 was not needed in the main body of the
security draft, but could be moved to an appendix or separate draft.  The
main body of the security draft does need to discuss important usage
scenarios
and the assumptions about what involved parties won't do in order to set
up applicability of threats and countermeasures to those scenarios.

STag invalidation is an important countermeasure, and the current structure
of RDDP functionality requires the ULP to check that invalidation occurred
and that the correct/expected STag was invalidated.  If not, the ULP will
need to do something (e.g., invalidate the STag that should have been
invalidated).

Q: Draft introduces Privileged Resource Manager as a mandatory functional
	component.  Does this have performance implications?
A: The intent is that it only be involved in high-frequency operations,
	but more work is needed to define the precise functionality of the
	Privileged Resource Manager and check if there are problems here.

It was noted that some countermeasures (e.g., limits on amount of non-
pageable host memory) may be part of the host OS itself as opposed to
the RDDP implementation.

--> Action Item: The "dual stack" architecture that came up in the MPA
draft discussion has security implications, as the point of "stack switch"
is an obvious place for an attacker to try something (e.g., louse up
the stack switch so that the connection has to be abandoned).  MPA
draft authors to look into this and post results of this investigation
to list.

-- iSER/DA drafts [G]

These two individual submission drafts concern iSCSI extensions for use
of RDMA (RDDP).  They were presented for the information of the WG, but
will not become RDDP WG work items.

_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp



From exim@www1.ietf.org  Mon Nov 17 17:09:50 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08869
	for <rddp-archive@odin.ietf.org>; Mon, 17 Nov 2003 17:09:50 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALrYr-000226-6T
	for rddp-archive@odin.ietf.org; Mon, 17 Nov 2003 17:09:33 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHM9Xpo007807
	for rddp-archive@odin.ietf.org; Mon, 17 Nov 2003 17:09:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALrYr-00021q-2I
	for rddp-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 17:09:33 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08821
	for <rddp-web-archive@ietf.org>; Mon, 17 Nov 2003 17:09:19 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALrYo-0007W6-00
	for rddp-web-archive@ietf.org; Mon, 17 Nov 2003 17:09:30 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALrYo-0007Vw-00
	for rddp-web-archive@ietf.org; Mon, 17 Nov 2003 17:09:30 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALrYL-0001zt-9y; Mon, 17 Nov 2003 17:09:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALrXn-0001yw-5u
	for rddp@optimus.ietf.org; Mon, 17 Nov 2003 17:08:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08803
	for <rddp@ietf.org>; Mon, 17 Nov 2003 17:08:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALrXk-0007VX-00
	for rddp@ietf.org; Mon, 17 Nov 2003 17:08:24 -0500
Received: from fmr01.intel.com ([192.55.52.18] helo=hermes.fm.intel.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALrXj-0007V5-00
	for rddp@ietf.org; Mon, 17 Nov 2003 17:08:23 -0500
Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39])
	by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hAHM44ZX017288
	for <rddp@ietf.org>; Mon, 17 Nov 2003 22:04:04 GMT
Received: from fmsmsxv041-1.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126])
	by talaria.fm.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAHM6iJ26165
	for <rddp@ietf.org>; Mon, 17 Nov 2003 22:06:44 GMT
Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.135])
 by fmsmsxv041-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003111714074522388
 ; Mon, 17 Nov 2003 14:07:45 -0800
Received: from fmsmsx402.amr.corp.intel.com ([132.233.42.200]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 17 Nov 2003 14:07:44 -0800
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Subject: RE: [rddp] Clause 3 comments for draft-ietf-rddp-ddp-01
Date: Mon, 17 Nov 2003 14:07:44 -0800
Message-ID: <6315617889C99D4BA7C14687DEC8DB4E0521872F@fmsmsx402.fm.intel.com>
Thread-Topic: [rddp] Clause 3 comments for draft-ietf-rddp-ddp-01
Thread-Index: AcOtOAWg4OuHiUuiTe+pxOC8MsilEgAHpgSQ
From: "Shah, Hemal" <hemal.shah@intel.com>
To: "Barry Reinhold" <bbr@lampreynetworks.com>, "RDDP" <rddp@ietf.org>
X-OriginalArrivalTime: 17 Nov 2003 22:07:44.0912 (UTC) FILETIME=[3A582100:01C3AD57]
X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: quoted-printable
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Barry,

Thanks for the comments!

I looked at the editorial comments below and all of them refer to not
use capitalization for the defined terms. I think the way it is in the
document is correct as the defined terms are capitalized in the spec.

So, I will not be making any changes based on your comments below.
Please let me know whether this addresses your comments below.

Hemal

-----Original Message-----
From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of
Barry Reinhold
Sent: Monday, November 17, 2003 12:23 PM
To: RDDP
Subject: [rddp] Clause 3 comments for draft-ietf-rddp-ddp-01

Below are comments on clause 3 of draft-ietf-rddp-ddp-01

There are 10 Editorial comments here all dealing with editorial nits.
This is only of interest to the editor(s).


Comments are given in the following form:

Number, type, significance, reference
Comment

CLAUSE 3

1, Editorial, Low 3 1st PP, page 3

Is: Direct Data Placement Protocol (DDP) enables an Upper Layer Protocol

   (ULP) to send data to a Data Sink without requiring the Data Sink to=20
   Place the data in an intermediate buffer - thus when the data=20
   arrives at the Data Sink, the network interface can Place the data=20
   directly into the ULP's buffer. This can enable the Data Sink to=20
   consume substantially less memory bandwidth than a buffered model=20
   because the Data Sink is not required to move the data from the=20
   intermediate buffer to the final destination. Additionally, this can=20
   also enable the network protocol to consume substantially fewer CPU=20
   cycles than if the CPU was used to move the data, and removes the=20
   bandwidth limitation of only being able to move data as fast as the=20
   CPU can copy the data.=20

Suggest: Direct Data Placement Protocol (DDP) enables an Upper Layer
Protocol=20
   (ULP) to send data to a data sink without requiring the data sink to=20
   place the data in an intermediate buffer - thus when the data=20
   arrives at the data sink, the network interface can place the data=20
   directly into the ULP's buffer. This can enable the data sink to=20
   consume substantially less memory bandwidth than a buffered model=20
   because the data sink is not required to move the data from the=20
   intermediate buffer to the final destination. Additionally, this can=20
   also enable the network protocol to consume substantially fewer CPU=20
   cycles than if the CPU was used to move the data, and removes the=20
   bandwidth limitation of only being able to move data as fast as the=20
   CPU can copy the data.=20
Changes: Removed capitalization on "data sink" and "place"

2, Editorial, Low 3.1 1st bullet page 4

Is:    =20
* Provide a buffer model that enables the Local Peer to Advertise=20
        a named buffer (i.e. a Tag for a buffer) to the Remote Peer,=20
        such that across the network the Remote Peer can Place data=20
        into the buffer at Remote Peer specified locations. This is=20
        referred to as the Tagged Buffer Model.=20

Suggest:    =20
* Provide a buffer model that enables the local peer to advertise=20
        a named buffer (i.e. a tag for a buffer) to the remote peer,=20
        such that across the network the remote peer can place data=20
        into the buffer at remote peer specified locations. This is=20
        referred to as the tagged buffer model.=20
Changes: removed capitalization of "local peer", "advertise", "remote
peer", tagged buffer model, and "place".

3, Editorial, Low 3.1, 2nd bullet page 4

Is:=20
     * Provide a second receive buffer model which preserves ULP=20
        message boundaries from the Remote Peer and keeps the Local=20
        Peer's buffers anonymous (i.e. Untagged). This is referred to=20
        as the Untagged Buffer Model.=20
Suggest:
     * Provide a second receive buffer model which preserves ULP=20
        message boundaries from the remote peer and keeps the local=20
        peer's buffers anonymous (i.e. untagged). This is referred to=20
        as the untagged buffer model.
Changes: removed capitalization

4, Editorial, Low 3.1, 3rd bullet page 4

Is:
     * Provide reliable, in-order Delivery semantics for both Tagged=20
        and Untagged Buffer Models. =20
Suggest:
     * Provide reliable, in-order delivery semantics for both Tagged=20
        and untagged buffer models.
Changes: Capitalization

5, Editorial, Low 3.1, 5th bullet page 4

Is:
     * Enable the ULP buffer to be used as a reassembly buffer,=20
        without a need for a copy, even if incoming DDP Segments arrive=20
        out of order. This requires the protocol to separate Data=20
        Placement of ULP Payload contained in an incoming DDP Segment=20
        from Data Delivery of completed ULP Messages.=20
Suggest:
     * Enable the ULP buffer to be used as a reassembly buffer,=20
        without a need for a copy, even if incoming DDP segments arrive=20
        out of order. This requires the protocol to separate data=20
        placement of ULP payload contained in an incoming DDP segment=20
        from data delivery of completed ULP messages.
Change: Capitalization

6 Editorial, Low 3.1 6th bullet page 4

Is:
     * If the LLP supports multiple LLP streams within a LLP=20
        Connection, provide the above capabilities independently on=20
        each LLP stream and enable the capability to be exported on a=20
        per LLP stream basis to the ULP.=20

Suggest:
     * If the LLP supports multiple LLP streams within a LLP=20
        connection, provide the above capabilities independently on=20
        each LLP stream and enable the capability to be exported on a=20
        per LLP stream basis to the ULP.
Change: Capitalization

7 Editorial, Low 3.2 1st three pps page 4

Is:
DDP supports two basic data transfer models - a Tagged Buffer data=20
   transfer model and an Untagged Buffer data transfer model. =20

   The Tagged Buffer data transfer model requires the Data Sink to send=20
   the Data Source an identifier for the ULP buffer, referred to as a=20
   Steering Tag (STag). The STag is transferred to the Data Source=20
   using a ULP defined method. Once the Data Source ULP has an STag for=20
   a destination ULP buffer, it can request that DDP send the ULP data=20
   to the destination ULP buffer by specifying the STag to DDP. Note=20
   that the Tagged Buffer does not have to be filled starting at the=20
   beginning of the ULP buffer. The ULP Data Source can provide an=20
   arbitrary offset into the ULP buffer. =20

   The Untagged Buffer data transfer model enables data transfer to=20
   occur without requiring the Data Sink to Advertise a ULP Buffer to=20
   the Data Source. The Data Sink can queue up a series of receive ULP=20
   buffers. An Untagged DDP Message from the Data Source consumes an=20
   Untagged Buffer at the Data Sink. Because DDP is message oriented,=20
   even if the Data Source sends a DDP Message payload smaller than the=20
   receive ULP buffer, the partially filled receive ULP buffer is=20
   Delivered to the ULP anyway. If the Data Source sends a DDP Message=20
   payload larger than the receive ULP buffer, it results in an error. =20

   There are several key differences between the Tagged and Untagged=20
   Buffer Model:=20
=20
Suggest:
DDP supports two basic data transfer models - a tagged buffer data=20
   transfer model and an untagged buffer data transfer model. =20

   The tagged buffer data transfer model requires the data sink to send=20
   the data source an identifier for the ULP buffer, referred to as a=20
   Steering Tag (STag). The STag is transferred to the data source=20
   using a ULP defined method. Once the data source ULP has an STag for=20
   a destination ULP buffer, it can request that DDP send the ULP data=20
   to the destination ULP buffer by specifying the STag to DDP. Note=20
   that the tagged buffer does not have to be filled starting at the=20
   beginning of the ULP buffer. The ULP data source can provide an=20
   arbitrary offset into the ULP buffer. =20

   The untagged buffer data transfer model enables data transfer to=20
   occur without requiring the data sink to advertise a ULP buffer to=20
   the data source. The data sink can queue up a series of receive ULP=20
   buffers. An untagged DDP message from the data source consumes an=20
   untagged buffer at the data sink. Because DDP is message oriented,=20
   even if the data source sends a DDP message payload smaller than the=20
   receive ULP buffer, the partially filled receive ULP buffer is=20
   delivered to the ULP anyway. If the data source sends a DDP message=20
   payload larger than the receive ULP buffer, it results in an error. =20

   There are several key differences between the tagged and untagged=20
   buffer model:=20

Changes: Capitalization

8 Editorial, Low, 3.2, bullets on page 5

Is:
     * For the Tagged Buffer Model, the Data Source specifies which=20
        received Tagged Buffer will be used for a specific Tagged DDP=20
        Message (sender-based ULP buffer management). For the Untagged=20
        Buffer Model, the Data Sink specifies the order in which=20
        Untagged Buffers will be consumed as Untagged DDP Messages are=20
        received (receiver-based ULP buffer management).=20

     * For the Tagged Buffer Model, the ULP at the Data Sink must=20
        Advertise the ULP buffer to the Data Source through a ULP=20
        specific mechanism before data transfer can occur. For the=20
        Untagged Buffer Model, data transfer can occur without an end-
        to-end explicit ULP buffer Advertisement. Note, however, that=20
        the ULP needs to address flow control issues.=20

     * For the Tagged Buffer Model, a DDP Message can start at an=20
        arbitrary offset within the Tagged Buffer. For the Untagged=20
        Buffer Model, a DDP Message can only start at offset 0.=20

     * The Tagged Buffer Model allows multiple DDP Messages targeted=20
        to a Tagged Buffer with a single ULP buffer Advertisement. The=20
        Untagged Buffer Model requires associating a receive ULP buffer=20
        for each DDP Message targeted to an Untagged Buffer. =20
Suggest:
     * For the tagged buffer model, the data source specifies which=20
        received tagged buffer will be used for a specific tagged DDP=20
        message (sender-based ULP buffer management). For the untagged=20
        buffer model, the data sink specifies the order in which=20
        untagged buffers will be consumed as untagged DDP messages are=20
        received (receiver-based ULP buffer management).=20

     * For the tagged buffer model, the ULP at the data sink must=20
        advertise the ULP buffer to the data source through a ULP=20
        specific mechanism before data transfer can occur. For the=20
        untagged buffer model, data transfer can occur without an end-
        to-end explicit ULP buffer advertisement. Note, however, that=20
        the ULP needs to address flow control issues.=20

     * For the tagged buffer model, a DDP message can start at an=20
        arbitrary offset within the tagged buffer. For the untagged=20
        buffer model, a DDP message can only start at offset 0.=20

     * The tagged buffer model allows multiple DDP messages targeted=20
        to a tagged buffer with a single ULP buffer advertisement. The=20
        untagged buffer model requires associating a receive ULP buffer=20
        for each DDP message targeted to an untagged buffer.=20
Change: Capitalization

9 Editorial, Low 3.2, text following bullets to end of clause

Is:
Either data transfer model Places a ULP Message into a DDP Message.=20
   Each DDP Message is then sliced into DDP Segments that are intended =20
=20
shah, et. al.             Expires April 2004                         5=20
=20
Internet-Draft        DDP Protocol Specification        October 2003=20
=20
   to fit within a lower-layer-protocol's (LLP) Maximum Upper Layer=20
   Protocol Data Unit (MULPDU). Thus the ULP can post arbitrary size=20
   ULP Messages, containing up to 2^32 - 1 octets of ULP Payload, and=20
   DDP slices the ULP message into DDP Segments which are reassembled=20
   transparently at the Data Sink. =20

   DDP provides in-order Delivery for the ULP. However, DDP=20
   differentiates between Data Delivery and Data Placement. DDP=20
   provides enough information in each DDP Segment to allow the ULP=20
   Payload in each inbound DDP Segment payloads to be directly Placed=20
   into the correct ULP Buffer, even when the DDP Segments arrive out-
   of-order. Thus, DDP enables the reassembly of ULP Payload contained=20
   in DDP Segments of a DDP Message into a ULP Message to occur within=20
   the ULP Buffer, therefore eliminating the traditional copy out of=20
   the reassembly buffer into the ULP Buffer.=20

   A DDP Message's payload is Delivered to the ULP when:=20

     * all DDP Segments of a DDP Message have been completely received=20
        and the payload of the DDP Message has been Placed into the=20
        associated ULP Buffer,=20

     * all prior DDP Messages have been Placed, and=20

     * all prior DDP Message Deliveries have been performed.=20

   The LLP under DDP may support a single LLP stream of data per=20
   connection (e.g. TCP) or multiple LLP streams of data per connection=20
   (e.g. SCTP). But in either case, DDP is specified such that each DDP=20
   Stream is independent and maps to a single LLP stream. Within a=20
   specific DDP Stream, the LLP Stream is required to provide in-order,=20
   reliable Delivery. Note that DDP has no ordering guarantees between=20
   DDP Streams.=20

   A DDP protocol could potentially run over reliable Delivery LLPs or=20
   unreliable Delivery LLPs. This specification requires reliable, in=20
   order Delivery LLPs.=20
Suggest:
Either data transfer model places a ULP message into a DDP message.=20
   Each DDP message is then sliced into DDP segments that are intended =20
=20
shah, et. al.             Expires April 2004                         5=20
=20
Internet-Draft        DDP Protocol Specification        October 2003=20
=20
   to fit within a lower-layer-protocol's (LLP) Maximum Upper Layer=20
   Protocol Data Unit (MULPDU). Thus the ULP can post arbitrary size=20
   ULP messages, containing up to 2^32 - 1 octets of ULP payload, and=20
   DDP slices the ULP message into DDP segments which are reassembled=20
   transparently at the data sink. =20

   DDP provides in-order delivery for the ULP. However, DDP=20
   differentiates between data delivery and data placement. DDP=20
   provides enough information in each DDP Segment to allow the ULP=20
   payload in each inbound DDP segment payloads to be directly placed=20
   into the correct ULP Buffer, even when the DDP Segments arrive out-
   of-order. Thus, DDP enables the reassembly of ULP payload contained=20
   in DDP segments of a DDP message into a ULP message to occur within=20
   the ULP buffer, therefore eliminating the traditional copy out of=20
   the reassembly buffer into the ULP buffer.=20

   A DDP message's payload is delivered to the ULP when:=20

     * all DDP segments of a DDP message have been completely received=20
        and the payload of the DDP message has been placed into the=20
        associated ULP buffer,=20

     * all prior DDP messages have been placed, and=20

     * all prior DDP message deliveries have been performed.=20

   The LLP under DDP may support a single LLP stream of data per=20
   connection (e.g. TCP) or multiple LLP streams of data per connection=20
   (e.g. SCTP). But in either case, DDP is specified such that each DDP=20
   stream is independent and maps to a single LLP stream. Within a=20
   specific DDP stream, the LLP stream is required to provide in-order,=20
   reliable delivery. Note that DDP has no ordering guarantees between=20
   DDP streams.=20

   A DDP protocol could potentially run over reliable delivery LLPs or=20
   unreliable delivery LLPs. This specification requires reliable, in=20
   order delivery LLPs.
Changes: Capitalization

10 Editorial Low 3.3 text before figure 1

Is:
   DDP enables direct data Placement capability for any ULP, but it has=20
   been specifically designed to work well with RDMAP (see [RDMA]), and=20
   is part of the iWARP protocol suite. =20
Suggest:
   DDP enables direct data placement capability for any ULP, but it has=20
   been specifically designed to work well with RDMAP (see [RDMA]), and=20
   is part of the iWARP protocol suite.=20
Change: Capitalization of "placement"=20
=20

Barry Reinhold
Lamprey Networks
bbr@lampreynetworks.com
(603) 868-8411
=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 exim@www1.ietf.org  Thu Nov 20 09:46:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06679
	for <rddp-archive@odin.ietf.org>; Thu, 20 Nov 2003 09:46:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMq4L-0007tb-Bm
	for rddp-archive@odin.ietf.org; Thu, 20 Nov 2003 09:46:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKEk5bP030347
	for rddp-archive@odin.ietf.org; Thu, 20 Nov 2003 09:46:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMq4L-0007tO-8e
	for rddp-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 09:46:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06668
	for <rddp-web-archive@ietf.org>; Thu, 20 Nov 2003 09:45:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMq4J-000441-00
	for rddp-web-archive@ietf.org; Thu, 20 Nov 2003 09:46:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMq4I-00043x-00
	for rddp-web-archive@ietf.org; Thu, 20 Nov 2003 09:46:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMq4I-0007sm-G4; Thu, 20 Nov 2003 09:46:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMq4C-0007sL-0r
	for rddp@optimus.ietf.org; Thu, 20 Nov 2003 09:45:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06654;
	Thu, 20 Nov 2003 09:45:42 -0500 (EST)
From: Black_David@emc.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMq4A-00043U-00; Thu, 20 Nov 2003 09:45:54 -0500
Received: from unk-for-smtp.isus.emc.com ([128.222.32.10] helo=mxic1.corp.emc.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMq49-000431-00; Thu, 20 Nov 2003 09:45:53 -0500
Received: by mxic1.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <W59MVCSP>; Thu, 20 Nov 2003 09:45:18 -0500
Message-ID: <B459CE1AFFC52D4688B2A5B842CA35EA02BF7351@corpmx14.corp.emc.com>
To: minutes@ietf.org, rddp@ietf.org
Date: Thu, 20 Nov 2003 09:45:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [rddp] RDDP WG final Minneapolis minutes
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>

RDDP WG Minneapolis meeting minutes
Tuesday, November 11, 2003, 0900-1130
-----------------------------------------

Letters in [square brackets] are the first letter of
file name of presentation that goes with each agenda item
in the proceedings.

-- Agenda Bashing and Administrivia [A]

No changes to agenda posted to mailing list.

-- Status of Drafts [B]

WG chair reviewed status of WG drafts.  See presentation
for details.  Security draft is on critical path for completion
of DDP and RDMAP - due to the current state of the security
draft, WG milestones are likely to move out by one IETF
meeting (about 3-4 months).

-- RDMA Applicability Statement [C]

In good shape.

-- DDP and RDMAP drafts [D]

Both are relatively stable, and have received minor updates
since Vienna.  An implementers note has been added to the DDP
draft to say that absence of a pre-allocated buffer for an
inbound untagged transfer does not need to immediately cause
an error that results in connection teardown - this was based
on extensive list discussion that concluded that implementations
should be allowed to keep a few "hidden" buffers to avoid (or
delay) the consequences of tearing down a connection.

The WG chair plans an initial WG Last Call on these drafts during
December, BUT they cannot be forwarded to the ADs/IESG until the
security draft is complete, and work on that draft will probably
cause additional changes to the DDP and RDMAP drafts.

-- SCTP Mapping [no presentation]

In relatively good shape.  One important open issue is that the
SCTP mapping allows Active/Active startup, whereas the TCP mapping
only allows Active/Passive.  This needs to be consistent across
both mappings, and will be resolved on the list - see Action Items
on this topic under the next agenda item.

-- TCP Mapping [E]

A number of changes have been made since the Vienna meeting:
- The Start Key is now 2 separate frames, so that it differs in
	each direction.
- Now using Initiator/Responder terms to designate roles in Active/
	Passive connection setup.  Discussion during the meeting
	suggested that while Initiator is also used to describe
	SCSI operation, there are no better terms readily available.
- "Private Data" support added.  Intention was to match SCTP support
	for this.
- Added support for "Immediate Startup" (RDDP protocols start up
	immediately at start of TCP connection) and example.

+ Active/Active startup issue. 

Draft authors prefer not to support Active/Active because it is
hard to get right in a "dual stack" system that switches between an
ordinary TCP (or SCTP) stack and an RDDP-enhanced one (e.g., in
hardware).  This needs to be taken to the list and resolved once
for both transports (either both TCP and SCTP support Active/Active, 
or neither does).  Action Items:

1) Draft authors to describe this problem including a sufficient
	functional model/description for a "dual stack" system to
	explain the implementation difficulty.
2) WG chair to ask on list whether any ULPs that are (or can be)
	anticipated to use RDDP need, want, or would benefit from
	Active/Active startup.

In connection with 2), it was asked whether SDP (Sockets Direct
Protocol) could become an RDDP WG work item.  The answer is "yes,
it could" - SDP draft authors should consult with WG chair (who
will consult with ADs as appropriate) when the SDP draft appears.
SDP does not require Active/Active startup, as sockets are
Active/Passive (listener is passive).

Immediate startup (RDDP starts when TCP connection is established) 
favors Active/Passive due to connection handshake - initiator of
handshake should initiate RDDP setup on the established TCP
connection.  SCTP uses adaption indications for this purpose.  Note
that in this case, the implementation has to "guess" what mode the
connection will start in, and if that "guess" is wrong, the
processing of data in the wrong mode on the wrong "stack" in a
"dual stack" system is likely to be unrecoverable - recovery would
have to be via connection close and some sort of retry (doing
something different to avoid a repetition).  Needs to be discussed
on list as part of above "dual stack" discussion.

+ Minor issues (see slides)

- Is single bit difference in Initiator vs. Responder start frame
	formats ok?  Probably, but needs to be discussed on list.
- How to reference Verbs draft, since IETF may not publish it?
	Informative reference to RDMAC version of verbs draft as an
	**example** should be ok.  Verbs draft cannot be used to
	impose requirements on RDDP.

+ Startup round-trip overheads

When ULP has exchanged data without RDDP and wants to switch into
RDDP mode, the resulting synchronization costs a round trip.  The
"dual stack" issue is an important motivation here.

For immediate startup, the first message of the setup round trip
can be combined with the TCP ACK that concludes the TCP connection
setup handshake, thus reducing the cost to half a round trip, but
that cost appears to be necessary in order to support private data
in a "dual stack" implementation.  Reducing this cost only helps if
Active/Active setup is required, or first data transfer is from TCP
Listener.

An issue was raised on the list about the MPA private data mechanism,
but no one at the meeting could reconstruct it accurately.

--> Needless to say, the "dual stack" issues need significant
discussion on the list, as consideration of this class of implementation
has had significant influence on the design decisions.  As part of this,
it will be necessary to check whether SCTP's use of adaption indications
changes any of these "dual stack" issues.

-- Security Draft [F]

Comprehensive presentation (see slides) due to an unfortunate conflict
in Vienna between the RDDP session in which security was discussed
and saag (Security Area) meeting.  The WG chair will do his best to
ensure that this sort of conflict does not occur in the future.

The sense of discussion in the room was that the partial trust taxonomy
and resulting matrix on slide 17 was not needed in the main body of the
security draft, but could be moved to an appendix or separate draft.
The main body of the security draft does need to discuss important
usage scenarios and the assumptions about what involved parties won't
do in order to set up applicability of threats and countermeasures to
those scenarios.

STag invalidation is an important countermeasure, and the current
structure of RDDP functionality requires the ULP to check that
invalidation occurred and that the correct/expected STag was
invalidated.  If not, the ULP will need to do something (e.g.,
invalidate the STag that should have been invalidated).

Q: Draft introduces Privileged Resource Manager as a mandatory
	functional component.  How does this affect performance?
A: The intent is that it not be involved in high-frequency
	operations, but more work is needed to define the precise
	functionality of the Privileged Resource Manager and check
	if there are problems.

It was noted that some countermeasures (e.g., limits on amount of
non-pageable host memory) may be part of the host OS itself as
opposed to the RDDP implementation.

--> Action Item: The "dual stack" architecture that came up in the
MPA draft discussion has security implications, as the point of
"stack switch" is an obvious place for an attacker to try something
(e.g., louse up the stack switch so that the connection has to be
abandoned).  MPA draft authors to look into this and post results
of their investigation to list.

-- iSER/DA drafts [G]

These two individual submission drafts concern iSCSI extensions for
use of RDMA (RDDP).  They were presented for the information of the
WG, but will not become RDDP WG work items.

_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp



From exim@www1.ietf.org  Thu Nov 20 14:06:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18920
	for <rddp-archive@odin.ietf.org>; Thu, 20 Nov 2003 14:06:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMu7w-0001cC-Nu
	for rddp-archive@odin.ietf.org; Thu, 20 Nov 2003 14:06:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKJ64uf006208
	for rddp-archive@odin.ietf.org; Thu, 20 Nov 2003 14:06:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMu7w-0001c3-JK
	for rddp-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 14:06:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18914
	for <rddp-web-archive@ietf.org>; Thu, 20 Nov 2003 14:05:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMu7u-0000V3-00
	for rddp-web-archive@ietf.org; Thu, 20 Nov 2003 14:06:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMu7t-0000V0-00
	for rddp-web-archive@ietf.org; Thu, 20 Nov 2003 14:06:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMu7u-0001ba-9e; Thu, 20 Nov 2003 14:06:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMu7l-0001aw-Dh
	for rddp@optimus.ietf.org; Thu, 20 Nov 2003 14:05:53 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18905
	for <rddp@ietf.org>; Thu, 20 Nov 2003 14:05:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMu7i-0000Um-00
	for rddp@ietf.org; Thu, 20 Nov 2003 14:05:50 -0500
Received: from mail1.microsoft.com ([131.107.3.125])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMu7i-0000Ug-00
	for rddp@ietf.org; Thu, 20 Nov 2003 14:05:50 -0500
Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0);
	 Thu, 20 Nov 2003 11:05:22 -0800
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069);
	 Thu, 20 Nov 2003 11:05:14 -0800
Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 20 Nov 2003 11:05:19 -0800
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069);
	 Thu, 20 Nov 2003 11:05:27 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069);
	 Thu, 20 Nov 2003 11:05:12 -0800
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);
	 Thu, 20 Nov 2003 11:05:18 -0800
x-mimeole: Produced By Microsoft Exchange V6.5.7097.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Date: Thu, 20 Nov 2003 11:05:16 -0800
Message-ID: <E6564B8F86852D46A4E98C485FB33B8F059998A0@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: Privileged Resource Manager comments
Thread-Index: AcOvlnx7KsXqWxUbTziF6VAqiPrfkg==
From: "Jim Pinkerton" <jpink@windows.microsoft.com>
To: "RDDP" <rddp@ietf.org>
X-OriginalArrivalTime: 20 Nov 2003 19:05:18.0089 (UTC) FILETIME=[3CC4BF90:01C3AF99]
Subject: [rddp] Privileged Resource Manager comments
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3AF99.3BCE8004"

------_=_NextPart_001_01C3AF99.3BCE8004
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

In the minutes for the last IETF meeting, it states:

=20

Q: Draft introduces Privileged Resource Manager as a mandatory

      functional component.  How does this affect performance?

A: The intent is that it not be involved in high-frequency

      operations, but more work is needed to define the precise

      functionality of the Privileged Resource Manager and check

      if there are problems.

=20

=20

In the latest draft, per feedback from the reflector, the following text
was added:

=20

For example, the Privileged Resource Manager may be partially or
completely encapsulated in the Privileged Application. Regardless, it is
expected that the security analysis of the potential threats and
countermeasures still apply.

=20

Thus I don't believe the draft requires a distinct entity called the
Privileged Resource Manager. It can be encapsulated in an application
that has been trusted to access privileged resources directly. For
example, a particular implementation may run exactly one application,
which has physical access to all resources. In that case the security
issues described for the non-privileged application are unnecessary to
implement (because there is not one), and there is no need to separate
the Privileged Resource Manager from the privileged application.

=20

=20

Jim

=20

=20

=20

=20


------_=_NextPart_001_01C3AF99.3BCE8004
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:.5in 66.25pt .5in 66.25pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In the minutes for the last IETF meeting, it =
states:</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Q: Draft introduces
Privileged Resource Manager as a mandatory</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; functional
component.&nbsp; How does this affect performance?</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>A: The intent is =
that it not
be involved in high-frequency</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; operations,
but more work is needed to define the precise</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; functionality
of the Privileged Resource Manager and check</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if
there are problems.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In the latest draft, per feedback from the reflector, =
the
following text was added:</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>For example, the Privileged Resource Manager may be partially or
completely encapsulated in the Privileged Application. Regardless, it is
expected that the security analysis of the potential threats and
countermeasures still apply.</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Thus I don&#8217;t believe the draft requires a distinct entity =
called the
Privileged Resource Manager. It can be encapsulated in an application =
that has
been trusted to access privileged resources directly. For example, a =
particular
implementation may run exactly one application, which has physical =
access to
all resources. In that case the security issues described for the
non-privileged application are unnecessary to implement (because there =
is not
one), and there is no need to separate the Privileged Resource Manager =
from the
privileged application.</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Jim</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C3AF99.3BCE8004--

--------------InterScan_NT_MIME_Boundary--


_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp



From exim@www1.ietf.org  Thu Nov 20 16:57:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01318
	for <rddp-archive@odin.ietf.org>; Thu, 20 Nov 2003 16:57:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMwnP-00085g-SQ
	for rddp-archive@odin.ietf.org; Thu, 20 Nov 2003 16:57:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKLv3pq031094
	for rddp-archive@odin.ietf.org; Thu, 20 Nov 2003 16:57:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMwnP-00085R-OL
	for rddp-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 16:57:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01222
	for <rddp-web-archive@ietf.org>; Thu, 20 Nov 2003 16:56:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMwnN-0004Vf-00
	for rddp-web-archive@ietf.org; Thu, 20 Nov 2003 16:57:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMwnN-0004VZ-00
	for rddp-web-archive@ietf.org; Thu, 20 Nov 2003 16:57:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMwnN-00084s-Gh; Thu, 20 Nov 2003 16:57:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMwmj-00080j-EJ
	for rddp@optimus.ietf.org; Thu, 20 Nov 2003 16:56:21 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01135
	for <rddp@ietf.org>; Thu, 20 Nov 2003 16:56:05 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMwmf-0004Tv-00
	for rddp@ietf.org; Thu, 20 Nov 2003 16:56:17 -0500
Received: from thebe.your-site.com ([140.186.45.26])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMwmc-0004OH-00
	for rddp@ietf.org; Thu, 20 Nov 2003 16:56:15 -0500
Received: from [192.168.0.101] (64-144-5-25.client.dsl.net [64.144.5.25])
	by thebe.your-site.com (Postfix) with ESMTP
	id 7F525244B3B; Thu, 20 Nov 2003 16:55:34 -0500 (EST)
In-Reply-To: <E6564B8F86852D46A4E98C485FB33B8F059998A0@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
References: <E6564B8F86852D46A4E98C485FB33B8F059998A0@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: multipart/alternative; boundary=Apple-Mail-1-863776769
Message-Id: <29ED14F0-1BA4-11D8-8F72-000393814604@asomi.com>
Cc: "RDDP" <rddp@ietf.org>
From: Caitlin Bestler <cait@asomi.com>
Subject: Re: [rddp] Privileged Resource Manager comments
Date: Thu, 20 Nov 2003 15:54:49 -0600
To: "Jim Pinkerton" <jpink@windows.microsoft.com>
X-Mailer: Apple Mail (2.606)
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>


--Apple-Mail-1-863776769
Content-Type: text/plain;
	charset=WINDOWS-1252;
	format=flowed
Content-Transfer-Encoding: quoted-printable


On Nov 20, 2003, at 1:05 PM, Jim Pinkerton wrote:

> =A0
>
> In the minutes for the last IETF meeting, it states:
>
> =A0
>
> Q: Draft introduces Privileged Resource Manager as a mandatory
>
> =A0=A0=A0=A0=A0 functional component.=A0 How does this affect =
performance?
>
> A: The intent is that it not be involved in high-frequency
>
> =A0=A0=A0=A0=A0 operations, but more work is needed to define the =
precise
>
> =A0=A0=A0=A0=A0 functionality of the Privileged Resource Manager and =
check
>
> =A0=A0=A0=A0=A0 if there are problems.
>
> =A0
>
> =A0
>
> In the latest draft, per feedback from the reflector, the following=20
> text was added:
>
> =A0
>
> For example, the Privileged Resource Manager may be partially or=20
> completely encapsulated in the Privileged Application. Regardless, it=20=

> is expected that the security analysis of the potential threats and=20
> countermeasures still apply.
>
> =A0
>
> Thus I don=92t believe the draft requires a distinct entity called the=20=

> Privileged Resource Manager. It can be encapsulated in an application=20=

> that has been trusted to access privileged resources directly. For=20
> example, a particular implementation may run exactly one application,=20=

> which has physical access to all resources. In that case the security=20=

> issues described for the non-privileged application are unnecessary to=20=

> implement (because there is not one), and there is no need to separate=20=

> the Privileged Resource Manager from the privileged application.
>
> =A0
>

Agreed, the "Privileged Resource Manager" is merely a label that=20
reflects the
fact that DDP Layer must be given permission to access user memory, and
that in most environments this fact must/should be validated.

But to be even more precise, the DDP Layer does not *have* to be given
access to "physical memory". The "RNIC" could be implemented *within*
a process, in which case the memory being accessed could be just
plain "normal" memory. The DDP Layer could also be operating over
a system bus with its own addressing (such as VME-64 or CPCI).




--Apple-Mail-1-863776769
Content-Type: text/enriched;
	charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable



On Nov 20, 2003, at 1:05 PM, Jim Pinkerton wrote:


=
<excerpt><fontfamily><param>Arial</param><x-tad-bigger>=A0</x-tad-bigger><=
/fontfamily>


<fontfamily><param>Arial</param><x-tad-bigger>In the minutes for the
last IETF meeting, it states:</x-tad-bigger></fontfamily>


=
<fontfamily><param>Arial</param><x-tad-bigger>=A0</x-tad-bigger></fontfami=
ly>


<fixed><fontfamily><param>Courier New</param><x-tad-bigger>Q: Draft
introduces Privileged Resource Manager as a =
mandatory</x-tad-bigger></fontfamily></fixed>


<fixed><fontfamily><param>Courier New</param><x-tad-bigger>=A0=A0=A0=A0=A0=

functional component.=A0 How does this affect =
performance?</x-tad-bigger></fontfamily></fixed>


<fixed><fontfamily><param>Courier New</param><x-tad-bigger>A: The
intent is that it not be involved in =
high-frequency</x-tad-bigger></fontfamily></fixed>


<fixed><fontfamily><param>Courier New</param><x-tad-bigger>=A0=A0=A0=A0=A0=

operations, but more work is needed to define the =
precise</x-tad-bigger></fontfamily></fixed>


<fixed><fontfamily><param>Courier New</param><x-tad-bigger>=A0=A0=A0=A0=A0=

functionality of the Privileged Resource Manager and =
check</x-tad-bigger></fontfamily></fixed>


<fixed><fontfamily><param>Courier New</param><x-tad-bigger>=A0=A0=A0=A0=A0=
 if
there are problems.</x-tad-bigger></fontfamily></fixed>


=
<fontfamily><param>Arial</param><x-tad-bigger>=A0</x-tad-bigger></fontfami=
ly>


=
<fontfamily><param>Arial</param><x-tad-bigger>=A0</x-tad-bigger></fontfami=
ly>


<fontfamily><param>Arial</param><x-tad-bigger>In the latest draft, per
feedback from the reflector, the following text was =
added:</x-tad-bigger></fontfamily>


=
<fontfamily><param>Arial</param><x-tad-bigger>=A0</x-tad-bigger></fontfami=
ly>


<fontfamily><param>Times New Roman</param><bigger><bigger>For example,
the Privileged Resource Manager may be partially or completely
encapsulated in the Privileged Application. Regardless, it is expected
that the security analysis of the potential threats and
countermeasures still apply.</bigger></bigger></fontfamily>


<fontfamily><param>Times New =
Roman</param><bigger><bigger>=A0</bigger></bigger></fontfamily>


<fontfamily><param>Times New Roman</param><bigger><bigger>Thus I don=92t
believe the draft requires a distinct entity called the Privileged
Resource Manager. It can be encapsulated in an application that has
been trusted to access privileged resources directly. For example, a
particular implementation may run exactly one application, which has
physical access to all resources. In that case the security issues
described for the non-privileged application are unnecessary to
implement (because there is not one), and there is no need to separate
the Privileged Resource Manager from the privileged =
application.</bigger></bigger></fontfamily>


<fontfamily><param>Times New =
Roman</param><bigger><bigger>=A0</bigger></bigger></fontfamily>


</excerpt>

Agreed, the "Privileged Resource Manager" is merely a label that
reflects the

fact that DDP Layer must be given permission to access user memory, and

that in most environments this fact must/should be validated.


But to be even more precise, the DDP Layer does not *have* to be given

access to "physical memory". The "RNIC" could be implemented *within*

a process, in which case the memory being accessed could be just

plain "normal" memory. The DDP Layer could also be operating over

a system bus with its own addressing (such as VME-64 or CPCI).





--Apple-Mail-1-863776769--


_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp



From exim@www1.ietf.org  Mon Nov 24 21:57:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17824
	for <rddp-archive@odin.ietf.org>; Mon, 24 Nov 2003 21:57:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOTNx-0004yE-4T
	for rddp-archive@odin.ietf.org; Mon, 24 Nov 2003 21:57:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP2v5An019099
	for rddp-archive@odin.ietf.org; Mon, 24 Nov 2003 21:57:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOTNw-0004xy-Vg
	for rddp-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 21:57:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17798
	for <rddp-web-archive@ietf.org>; Mon, 24 Nov 2003 21:56:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOTNt-0003p5-00
	for rddp-web-archive@ietf.org; Mon, 24 Nov 2003 21:57:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOTNt-0003p1-00
	for rddp-web-archive@ietf.org; Mon, 24 Nov 2003 21:57:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOTNt-0004xa-W4; Mon, 24 Nov 2003 21:57:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOTNV-0004ws-N1
	for rddp@optimus.ietf.org; Mon, 24 Nov 2003 21:56:38 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17780
	for <rddp@ietf.org>; Mon, 24 Nov 2003 21:56:21 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOTNS-0003oY-00
	for rddp@ietf.org; Mon, 24 Nov 2003 21:56:34 -0500
Received: from mail2.microsoft.com ([131.107.3.124])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOTNR-0003o5-00
	for rddp@ietf.org; Mon, 24 Nov 2003 21:56:34 -0500
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041);
	 Mon, 24 Nov 2003 18:55:48 -0800
Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 24 Nov 2003 18:55:59 -0800
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069);
	 Mon, 24 Nov 2003 18:56:00 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0);
	 Mon, 24 Nov 2003 18:56:09 -0800
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);
	 Mon, 24 Nov 2003 18:56:20 -0800
Content-class: urn:content-classes:message
Subject: RE: [rddp] Clarification on intent of requirement
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 24 Nov 2003 18:53:29 -0800
Message-ID: <E6564B8F86852D46A4E98C485FB33B8F05A13CB8@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
x-mimeole: Produced By Microsoft Exchange V6.5.7122.0
Thread-Topic: [rddp] Clarification on intent of requirement
thread-index: AcOtHzxPzCFBcn+3Q+S0mxaZY11O8wF33BJQ
From: "Jim Pinkerton" <jpink@windows.microsoft.com>
To: "Caitlin Bestler" <cait@asomi.com>,
        "Barry Reinhold" <bbr@lampreynetworks.com>
Cc: "RDDP" <rddp@ietf.org>
X-OriginalArrivalTime: 25 Nov 2003 02:56:20.0657 (UTC) FILETIME=[B4396210:01C3B2FF]
Content-Transfer-Encoding: quoted-printable
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable


I agree with what Caitlin said, with one further comment. This
requirement is really there to require the LLP to keep a message length
(for a byte stream like TCP) or have datagram semantics (for an LLP like
SCTP) such that a DDP segment can be pulled out intact at the opposite
end.=20

I don't see that this talks in any way to an indication mechanism. This
is outside the scope of a wire protocol.




Jim



> -----Original Message-----
> From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of
> Caitlin Bestler
> Sent: Monday, November 17, 2003 7:26 AM
> To: Barry Reinhold
> Cc: RDDP
> Subject: Re: [rddp] Clarification on intent of requirement
>=20
>=20
> On Nov 17, 2003, at 9:01 AM, Barry Reinhold wrote:
>=20
> > Clause 5 item 4 of draft-ietf-rddp-ddp-01 states:
> >
> >    4.  The LLP MUST preserve DDP Segment and Message boundaries at
the
> >        Data Sink.
> >
> > For the LLP to preserve the DDP segment boundary I would expect that
> > the
> > LLP (MPA/SCTP) would, in some virtual API, provides an indication
that
> > the DDP segment is available (i.e. the full DDP segment is available
in
> > some buffer and is without error). Given an API this could be
tested.
> >
> > I am not clear on what the LLP is supposed to do with a DDP message
> > boundary. A DDP message boundary is defined by a bit in a DDP header
> > and
> > the semantics associated with processing a DDP message do not seem
to
> > be
> > appropriate for the LLP. In what way is the LLP supposed to
"preserve"
> > a
> > DDP message?
> >
> >
>=20
> The requirement that the LLP "preserve Message boundaries" is perhaps
> misleading, because it is merely preserving the portion of the segment
> that indicates it is a message boundary. But the LLP is preserving the
> entire message, with no understanding of its internal structure, so of
> course it preserve whatever portion is responsible for marking message
> boundaries. If the draft authors want to clean the language up, fine,
> but it certainly is not an error as written.
>=20
> Preserving Segment boundaries is more important, and what I understood
> the primary purpose of the clause to be. It is a re-affirmation that
> the service offered by the LLP is reliable delivery of DDP Segments,
> not byte streams.
>=20
> Also, keep in mind that the virtual API between the LLP and DDP is
> allowed to have *two* methods: one for placement and a second for
> completion. At the time LLP completion is reported, the information
> on where the DDP Segment boundaries were must not have been lost.
> In particular the fact that TCP has acked a *portion* of a DDP Segment
> has no meaning to the DDP layer. It is not LLP completed until the
> entire segment has been LLP acked.
>=20
> For the SCTP mapping, each DDP Segment is a single-chunk SCTP User
> Message, so there are no potential conflicts.
>=20
>=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 exim@www1.ietf.org  Thu Nov 27 14:59:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16338
	for <rddp-archive@odin.ietf.org>; Thu, 27 Nov 2003 14:59:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1APSI3-000111-6P
	for rddp-archive@odin.ietf.org; Thu, 27 Nov 2003 14:59:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hARJx354003899
	for rddp-archive@odin.ietf.org; Thu, 27 Nov 2003 14:59:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1APSI3-00010o-2V
	for rddp-web-archive@optimus.ietf.org; Thu, 27 Nov 2003 14:59:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16334
	for <rddp-web-archive@ietf.org>; Thu, 27 Nov 2003 14:58:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1APSI0-0004R3-00
	for rddp-web-archive@ietf.org; Thu, 27 Nov 2003 14:59:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1APSHz-0004Qy-00
	for rddp-web-archive@ietf.org; Thu, 27 Nov 2003 14:58:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1APSI0-00010Q-U0; Thu, 27 Nov 2003 14:59:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1APSHd-0000zM-3S
	for rddp@optimus.ietf.org; Thu, 27 Nov 2003 14:58:37 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16329
	for <rddp@ietf.org>; Thu, 27 Nov 2003 14:58:22 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1APSHa-0004Qv-00
	for rddp@ietf.org; Thu, 27 Nov 2003 14:58:34 -0500
Received: from ns1.s2io.com ([216.209.86.101])
	by ietf-mx with esmtp (Exim 4.12)
	id 1APSHZ-0004Qo-00
	for rddp@ietf.org; Thu, 27 Nov 2003 14:58:33 -0500
Received: from guinness.s2io.com (gateway.s2io.com [216.209.86.98])
	by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id hARJh1FG021989;
	Thu, 27 Nov 2003 14:43:01 -0500 (EST)
Received: from lgmobile (dhcp-6-6 [10.16.6.6])
	by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id hARJgve8029532;
	Thu, 27 Nov 2003 14:42:58 -0500 (EST)
From: "Serag GadelRab" <Serag.Gadelrab@s2io.com>
To: "'Caitlin Bestler'" <cait@asomi.com>, <rddp@ietf.org>
Cc: "'Michael Krause'" <krause@cup.hp.com>
Subject: RE: [rddp] DDP 7.3 - Data Source MUST transmit DDP Messages in order
Date: Thu, 27 Nov 2003 14:52:40 -0500
Message-ID: <003701c3b520$0517e9a0$9865fea9@pc.s2io.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.3416
In-Reply-To: <D0989534-1073-11D8-A3F0-003065D48EE0@asomi.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
X-Spam-Score: -106.8
X-Spam-Outlook-Score: ()
X-Spam-Features: BAYES_01,IN_REP_TO,ORIGINAL_MESSAGE,SIGNATURE_LONG_SPARSE,USER_IN_WHITELIST
X-Scanned-By: MIMEDefang 2.34
Content-Transfer-Encoding: 7bit
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>,
	<mailto:rddp-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


From an implementation point of view, handling out-of-order DDP segments
within  in-order TCP flow is not going to come for free.  Special HW
will have to be added to ensure that this case is handled properly since
it does not correspond exactly to the case where the TCP segments arrive
out of order.

The question is whether this added complexity in receivers is warranted.
I doubt that any transmitters will try to engage in such optimizations
due to the complexity of scheduling OOO DDP segments.  Moreover, one
could argue that this type of optimization is not necessary since the
data that needs to be transmitted will almost certainly be resident in
host memory when the transmit WQE is generated to the RNIC; so why
burden receivers with such a functionality when it will probably be
never exhibited by a transmitter?

Serag



-----Original Message-----
From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of
Caitlin Bestler
Sent: Thursday, November 06, 2003 11:11 AM
To: rddp@ietf.org
Cc: Michael Krause
Subject: RE: [rddp] DDP 7.3 - Data Source MUST transmit DDP Messages in
order



Michael Krause's replied to my post as follows:

 >> I would request the following:
 >>
 >> - Does the WG agree that the current wording is compatible
 >>   with both interpretations? Or is the latter interpretation
 >>   locked in by some other language the at I overlooked?

 >> - If there is agreement that the current language is at
 >>   least potentially ambiguous, is there any objection to
 >>   adding the clarification that all DDP Segments for a
 >>   DDP Message must be submitted for transmission to the
 >>   LLP before any Segment for a following DDP Message.

 > Implementations should be able to deal with OOO packet delivery and 
being
 > able to target multiple receive buffers if they are posted (shared or

  exclusive).
 > Given there is no delta in the wire protocol or the expected  
interoperability in
 > this respect, I do not favor trying to tighten how the  transmitter 
is implemented
 > as that is potentially delving into the specific  design options in 
the hardware.
 >
 > Mike

Generally, I am in full agreement. Receivers should be as flexible as 
possible
and senders should be given as much freedom as possible.

But the purpose of that is to allow senders to find potential 
optimizations
in ways that might not have been obvious. For example, mandating that a
message MUST be segmented in a certain way would block a sender from 
optimizing
for a DDP Segment that might have piggy-packed in the same SCTP Packet 
or TCP
Segment that was already partially filled.

But I'm not sure I can see any benefit to the senders of working ahead,
especially when the last segments must be sent in order and when for 
many
ULPs almost all untagged messages will fit in a single segment.

On the receiving side, however, the restriction can be beneficial to an
entire *class* of implementations -- those that ride on top of optimized
TCP solutions.

Since we have made it clear that the receiver does not have to 
pre-commit
receive buffer for untagged messages (as in the class receive queue) we
have implicitly allowed for receivers that must fetch buffers "on 
demand".

Whatever implementation is used, clearly having a limit on the number of
fetched buffers that have not completed will result in a simpler 
problem.

Simplifying the problem is legitimate. Yes it benefits certain 
implementations,
but that is because it simplified the problem.

Admittedly, the proposed restriction is of virtually no benefit to
implementations that process DDP Segments in arrival order. For that
reason it would be wrong to impose any costs on those implementations
for this feature. But there is no impact on out-of-order receivers.

The *only* impact is that it might block hyper-aggressive re-ordering of
unsent pending DDP Segments. Even with this proposed additional
language, such re-ordering is still possible *within* an untagged
message and with tagged segments. In my opinion that is more than enough
slack for potential optimizations (in fact I suspect that very few
implementations are even considering such optimizations).






-- 
Caitlin Bestler - cait@asomi.com - http://asomi.com/
http://asomi.com/CaitlinBestlerPublicPgpKey.html


_______________________________________________
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