RE: [rddp] DDP draft specification
"Sanjay Goyal" <sanjayg@ivivity.com> Sun, 28 August 2005 00:47 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9BKg-0005UN-2m; Sat, 27 Aug 2005 20:47:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jMp-0000bq-Lf for rddp@megatron.ietf.org; Fri, 26 Aug 2005 14:55:55 -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 OAA06606 for <rddp@ietf.org>; Fri, 26 Aug 2005 14:55:54 -0400 (EDT)
Received: from [64.238.111.98] (helo=thoth.ivivity.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8jNY-0000HP-US for rddp@ietf.org; Fri, 26 Aug 2005 14:56:44 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [rddp] DDP draft specification
Date: Fri, 26 Aug 2005 14:55:42 -0400
Message-ID: <0F31272A2BCBBE4FA01344C6E69DBF50295F4C@thoth.ivivity.com>
Thread-Topic: [rddp] DDP draft specification
Thread-Index: AcWkzMUYjSnM7bjwQA+jjlp2vf35eQAFlAwAAEeSVSABGj9dMA==
From: Sanjay Goyal <sanjayg@ivivity.com>
To: Caitlin Bestler <caitlinb@broadcom.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sat, 27 Aug 2005 20:47:32 -0400
Cc: rddp@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" <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>
Sender: rddp-bounces@ietf.org
Errors-To: rddp-bounces@ietf.org
Hi, What you described is the distinction between placement and delivery. Thanks for the elaboration. The point I am trying to make is that MPA FPDU even if they arrive out-of-order can be placed in the memory as DDP header has the placement information. DDP preserves ULP message boundaries and uses MSN to keep track of in-order deliveries and MPA layer has none of these characteristics. So when a MPA FPDUs arrives, it is processed for CRC/markers and is given to DDP for it to be placed in the memory. Or in other words MPA only delivers FPDUs to DDP and does not really place the data. So the below sentence still does not make sense to me. This specification requires reliable, in order Delivery LLPs. Because the above sentence will mean that out-of-order DDP segment will really never be received. Best Regards, Sanjay Goyal -----Original Message----- From: Caitlin Bestler [mailto:caitlinb@broadcom.com] Sent: Saturday, August 20, 2005 11:44 PM To: Sanjay Goyal Cc: rddp@ietf.org Subject: RE: [rddp] DDP draft specification > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On > Behalf Of Sanjay Goyal > Sent: Friday, August 19, 2005 10:29 AM > To: rddp@ietf.org > Subject: [rddp] DDP draft specification > > 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? > > Regards, > > Sanjay > The first clause allows DDP to place data into buffers in the order that the LLP provides DDP Segments for the purpose of placement. The second clause specifies that the LLP will only *deliver* the DDP Segments in order. DDP itself provides for in-order delivery only after LLP delivery. Placement deals with buffering. Placement alone does not enable the data to be used. See the rules about buffers being undefined until delivery. Basically the same distinction between placement and delivery that applies for DDP can apply between the LLP and DDP. But that is implementation specific since there is no standardization of the DDP/LLP interface. It was a design goal that the classic sockets interface be an acceptable interface, but it is no way mandated or even suggested. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp
- [rddp] DDP draft specification Sanjay Goyal
- Re: [rddp] DDP draft specification Sukanta ganguly
- Re: [rddp] DDP draft specification Caitlin Bestler
- RE: [rddp] DDP draft specification Caitlin Bestler
- Re: [rddp] DDP draft specification Michael Krause
- RE: [rddp] DDP draft specification Sanjay Goyal
- Re: [rddp] DDP draft specification David Robinson