Re: [rddp] DDP draft specification

Michael Krause <krause@cup.hp.com> Mon, 22 August 2005 14:01 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Cs5-0006xA-7M; Mon, 22 Aug 2005 10:01:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Cs3-0006x2-6k for rddp@megatron.ietf.org; Mon, 22 Aug 2005 10:01:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16647 for <rddp@ietf.org>; Mon, 22 Aug 2005 10:01:46 -0400 (EDT)
Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7DSX-0001k0-36 for rddp@ietf.org; Mon, 22 Aug 2005 10:39:36 -0400
Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel10.hp.com (Postfix) with ESMTP id 71EF2215A for <rddp@ietf.org>; Mon, 22 Aug 2005 07:01:43 -0700 (PDT)
Received: from MK73191c.cup.hp.com ([15.244.202.163]) by esmail.cup.hp.com (8.9.3 (PHNE_29774)/8.8.6) with ESMTP id GAA25459 for <rddp@ietf.org>; Mon, 22 Aug 2005 06:54:24 -0700 (PDT)
Message-Id: <6.2.0.14.2.20050822070006.0276e690@esmail.cup.hp.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Mon, 22 Aug 2005 07:01:04 -0700
To: rddp@ietf.org
From: Michael Krause <krause@cup.hp.com>
Subject: Re: [rddp] DDP draft specification
In-Reply-To: <86EFBDEB-14DE-428C-A9E1-CBAFACEA008C@asomi.com>
References: <0F31272A2BCBBE4FA01344C6E69DBF50295F3A@thoth.ivivity.com> <86EFBDEB-14DE-428C-A9E1-CBAFACEA008C@asomi.com>
Mime-Version: 1.0
X-Spam-Score: 2.0 (++)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=unsubscribe>
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-Type: multipart/mixed; boundary="===============1858973297=="
Sender: rddp-bounces@ietf.org
Errors-To: rddp-bounces@ietf.org

At 07:15 PM 8/21/2005, Caitlin Bestler wrote:

>On Aug 19, 2005, at 10:28 AM, Sanjay Goyal wrote:
>
>>Hi,
>>
>>The below 2 sentences are from draft-ietf-rddp-ddp-05.txt
>>
>>1. 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.
>>2. This specification requires reliable, in order Delivery LLPs.
>>
>>First sentence says that DDP segments which are MPA FPDUs in TCP
>>case can arrive out-of-order and
>>second sentence says that LLP (MPA layer) needs to provide ordered
>>delivery. Isn't it contradictory?
>
>The same distinction between placement and delivery that applies for
>RDMAP and DDP
>MAY apply to the DDP/LLP interface.
>
>The DDP/LLP interface is not standardized, but the essence is that:
>
>1) the LLP MAY supply DDP Segments in the order received (some might
>even say SHOULD).
>     The adaptation layers for TCP and SCTP are specifically designed
>to enable this by providing
>     sufficient data to enable placement even when LLP re-ordering
>has occurred.
>2) The LLP MUST still indicate in-order delivery to DDP. DDP needs
>this because it MUST NOT
>      deliver anything to RDMAP that was not fully delivered by the LLP.
>
>One of the review criteria that the IETF RDDP work group insisted on
>was that DDP must
>be implementable over a standards socket interface. DDP in fact
>allows this, but that interface
>does not provide optimization for out-of-order placement.
>
>An implementation can define its own DDP/LLP interface that
>distinguishes between
>placement and delivery. Such an interface can even be described as
>"cleanly layered",
>it just isn't using the classic sockets interface to define the clean
>layering.

Side note: There is also a new Sockets Extension API that adds memory 
management, event management, async comms, etc. that people should take a 
look at since it is a Unix standard.  It will work well for RDMA / SDP.

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