RE: DDP segment sequences for Untagged DDP message

Pat,
	Given clause 7.4, which states...

   At the Data Sink, DDP MUST Deliver a DDP Message if and only if all 
   of the following are true: 

     * the last DDP Segment of the DDP Message had its Last flag set,  

     * all of the DDP Segments of the DDP Message have been Placed, 

     * all preceding DDP Messages have been Placed, and 

     * each preceding DDP Message has been Delivered to the ULP. 

I assumed that DDP could not deliver the "DDP message" until the second
segment of the message arrived (this would have violated item 2 above).

I am also assuming that item 2 exists to ensure that an LLP error, which
has caused a DDP segment to arrive out of order, does not cause a DDP
message to be delivered prematurely. (This is distinct from the DDP
transmitter sending requirements for the L bit.)

What I "think I hear you saying..." is that item 2 does not have to be
checked before delivery of the message. If this is what you are saying,
how is premature delivery avoided?

Would the following be acceptable wording?

At the Data Sink, DDP MUST NOT Deliver a DDP Message until all of the
following conditions are true: 

     * a DDP segment with the L bit set has been placed for this DDP
message

     * all octets, based on LLP sequence information, have been placed
for this DDP message.

     * all preceding DDP Message have been Delivered to the ULP.

The wording above removes the word "last" from the first item of the
original requirement, which I believe is ambiguous, but allows
implementations to track LLP sequence information to avoid score
boarding, and addresses the premature delivery issue. If the above
wording is used then the behavior of the DDP layer, in the case below,
would be to wait for the second DDP segment to arrive before the DDP
message is delivered to the ULP. The ULP would see a message of 200
bytes with no gaps.

If, for some reason that I have overlooked, it is not possible to get an
out of order DDP segment due to LLP error recovery, then I agree with
Pat and the second item of the original requirement for delivery of a
DDP message is not necessary.



-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Friday, January 23, 2004 4:22 PM
To: [email protected]; [email protected]
Cc: [email protected]
Subject: RE: [rddp] DDP segment sequences for Untagged DDP message

This should be shown as:

1. QN = 0, MSN = 1, MO = 100 L = 1 Payload = 100 bytes
Result: DDP Message (bytes 0-200) is delivered to ULP
2. QN = 0, MSN = 1, MO = 0   L = 0 Payload = 100 bytes
Result: Error is reported Invalid MSN - MSN range is not valid
This is a fatal error so there will be a teardown.
 
Pat

-----Original Message-----
From: Caitlin Bestler [mailto:[email protected]]
Sent: Friday, January 16, 2004 4:42 PM
To: RDDP
Cc: Barry Reinhold
Subject: Re: [rddp] DDP segment sequences for Untagged DDP message



On Jan 16, 2004, at 1:08 PM, Barry Reinhold wrote:

>
> So, is there agreement, for the sequences that follow, that the
> specified "result" given below is the correct (and desired?) behavior 
> as
> defined by the 01 draft.
>
> Untagged DDP Segment Sequences:
>
> 1. QN = 0, MSN = 1, MO = 100 L = 1 Payload = 100 bytes
> 2. QN = 0, MSN = 1, MO = 0   L = 0 Payload = 100 bytes
> Result: DDP Message (bytes 0-200) is delivered to ULP
>

Did you mean to set the 'L' bit on message 1?

If so, that is a sender violation, which as explained in Paul's
response may or may not be caught by the receiver.

If Msg 1 is completed *before* Msg 2 is placed, Msg 2 will
be rejected as having an invalid MSN (it would be taken as
being 2**32-1 ahead of the current location).

In either case a 200 byte receive will be reported to the ULP.
The question is whether the Stream is almost immediately
thereafter torn down.

-- 
Caitlin Bestler - [email protected] - http://asomi.com/
http://asomi.com/CaitlinBestlerPublicPgpKey.html


_______________________________________________
rddp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rddp