Subject: RE: [rddp] DDP draft specification

From: "Sanjay Goyal" <[email-masked]>
Date: Fri, 26 Aug 2005 14:55:42 -0400

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:[email-masked]]
Sent: Saturday, August 20, 2005 11:44 PM
To: Sanjay Goyal
Cc: [email-masked]
Subject: RE: [rddp] DDP draft specification

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Sanjay Goyal
> Sent: Friday, August 19, 2005 10:29 AM
> To: [email-masked]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: David Robinson <[email-masked]>
Date: Sun, 28 Aug 2005 23:03:04 -0500

Sometime it helps to think of the architecture in its pure layered
implementation instead of examine how it will actually
be implemented to understand the distinction between placement
and delivery.

The primary requirement is that the LLP is reliable and
an in order delivery protocol.  In a pure implementation
DDP will *never* see a packet that is not in order or
out of sequence.  In this pure case the distinction between
delivery and placement is moot.  But the impact of such pure
layering is that an out of order segment will cause the LLP
to force a retransmit or perform a copy to an intermediate
buffer before delivery (i.e. SACK). This is a perfectly acceptable
solution but suffers from either decreased bandwidth due to
retransmissions or increased overhead due to copies and buffer
consumption.  Both of what DDP is trying to avoid.

If you add the distinction of placement and delivery, a common
implementation can mostly avoid the problems of out of
order or lost segments. In a reliable LLP, before a delivery
notification, an ULP can assume nothing about the contents
of a buffer as they may change at any time up until
delivery notification. The LLP can take advantage of this
by working around the layering when it receives out
of order data. It can examine the DDP headers to determine
where the data should be placed to eliminate the intermediate
buffering.  But because it cannot make a delivery notification
the ULPs can't know or reliably determine if placement has
occurred. Once all of the intermediate segments have arrived
then delivery notification can occur. There are things that
can cause the placement to be invalidated, from the mundane
bad CRC to something more complex like the connection reset
before the missing segment arrives. Fortunately those things
are very rare.

>  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.
>

So this does make sense if you consider that 'delivery' may not
actual cause any data to be moved, it may simply be validation that
a buffer is usable. So the LLP may 'place' data out of order or
unreliably, if this speculative placement was correct then
'delivery' is a trivial operation. So your last statement
is not correct, DDP will by definition *never* see an out of order DDP
segment so the issue of if it was 'received' doesn't make sense. What
it does see is an in order sequence of segments that if it violated
the layering and snooped the memory buffers, it may detect that the
memory was not filled in the expected ordering, or in some cases the
same memory may have been written multiple times.  There is no
'reception' until delivery, regardless of the contents of the
destination buffers.

	-David