Subject: RE: [rddp] DDP segment sequences for Untagged DDP message

From: [email-masked]
Date: Fri, 23 Jan 2004 14:22:13 -0700

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-masked]]
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-masked] - http://asomi.com/
http://asomi.com/CaitlinBestlerPublicPgpKey.html

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

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

---

From: "Barry Reinhold" <[email-masked]>
Date: Mon, 26 Jan 2004 13:36:09 -0500

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-masked] [mailto:[email-masked]] 
Sent: Friday, January 23, 2004 4:22 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [rddp] DDP segment sequences for Untagged DDP message

This should be shown as:

Pat

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 26 Jan 2004 13:45:03 -0600

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

Well yes, the essential requirement is "everything prior placed"
and "prior messages completed". But I do not think this wording
is any clearer than the original, and the second clause is almost
misleading in its use of "all octets" and "for this DDP message".

The DDP Layer does not know truly understand what inbound messages
are. All that it knows is that all portions of the message are in
or earlier than (in LLP sequence) than the segment with the L bit
(and that the segment with the L bit has the highest MO if untagged).

So the DDP Layer only knows when all octets for this LLP Sequence
has been placed because it knows when all octets for all prior
packets (based on LLP Sequence) have been placed -- but it has
no recollection about which of those bytes were for any given
message.

The intent here is to 'scoreboard' the LLP stream, not messages.
This is especially valuable because the LLP is doing so already.

The second clause also implies that LLP sequence information
is somehow byte related. When the transport is SCTP this is
not the case. Indeed the "LLP Sequence" might not even match
the actual transmit order because the sending stack is allowed
to re-order Data Chunks to optimize chunk bundling.