RE: DDP segment sequences for Untagged DDP message

Pat, Caitlin, Paul,
	I think several different issues have come up, as I formulated
my initial post somewhat poorly. I would like to clarify it a bit to see
if we have agreement.

Definition of terms:

QN - Queue Number in the header of the untagged DDP message

MSN - Message Sequence number in the header of the untagged DDP message

L - L bit in the header of the untagged DDP message

Payload - The number of bytes in the payload of the DDP segment

LLPSeqNumTag - Assume this to be the LLP Sequence number associated with
the last octet of the DDP Segment received.

LLPSegNumCompleted - Assume this to be an LLP maintained value that
indicates that all octets in the LLP stream up to the value indicated
have been placed. 

I recognize that LLPSegNumTag and LLPSegNumCompleted do not exist in the
draft, but I don't see how to clearly specify the problem with terms
currently defined in the draft. 
Also note that, for simplicity reasons, the LLP sequence numbers just
follow DDP payload data, they are not real LLP sequence numbers. (The
only condition that needs to be testable is if the LLPSeqNumCompleted
matches the LLPSegNumTag of the segment with the L bit set to 1.)


Case 1

DDP segments as seen in time order at the receiver: 
1. QN = 0, MSN = 1, MO = 100, L = 1, Payload = 100, LLPSegNumCompleted =
500, LLPSeqNumTag = 600
2. QN = 0, MSN = 1, MO = 000, L = 0, Payload = 100, LLPSeqNumCompleted =
600, LLPSegNumTag = 500

Is the ONLY correct behavior to deliver 200 bytes of data to the ULP
upon reception of the second (item 2.) DDP segment?

Case 2
DDP segments as seen in time order at the receiver:
1. QN = 0, MSN = 1, MO = 100, L = 1, Payload = 100, LLPSegNumCompleted =
600, LLPSegNumTag = 600
2. QN = 0, MSN = 1, MO = 000, L = 0, Payload = 100, LLPSegNumCompleted =
500, LLPSegNumTag = 500

(In this case the transmitter has violated 6.1 which states:
        The DDP Segment with the L bit set to 1 MUST be posted to the 
        LLP after all other DDP Segments of the associated DDP Message 
        have been posted to the LLP. )

Agree/disagree (by part)

There are two "allowed" behaviors after reception of item 1. 
1. sending the ULP 200 bytes of data
2. sending the ULP an error message (not currently defined)

The ONLY correct behavior on reception of item 2 is to send the ULP the
error (0x03 - invalid MSN - MSN range is not valid)



-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Caitlin Bestler
Sent: Tuesday, January 27, 2004 9:59 AM
To: Paul Culley; RDDP
Subject: Re: [rddp] DDP segment sequences for Untagged DDP message


On Jan 27, 2004, at 8:01 AM, Culley, Paul wrote:

> OK, I realize that I missed a small point; in the first case below
>
>   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
>   [prc] yes
>   [pat]DDP message (bytes 0-200) occurs after 1.
>      2 will cause an invalid MSN error
>
> I was thinking of TCP segments as they arrive at the receiver, not as
> sent at the transmitter.  If the example was sent in this order, I 
> agree
> that an invalid MSN error is the correct answer,

The MSN is invalid, but the receiver is not obligated to catch it.

If DDP-Segment 2 is placed *before* DDP-Segment 1 is completed, then
no error will be detected. Both the MO and MSN are in range. The
100 bytes will be placed.

This obviously can occur if DDP-Segment 2 arrives before DDP-Segment 1.
But it can also occur if they arrive in order and the receiver
pipelines processing of DDP-Segments. Remember that all implications
of out-of-order processing hold no matter what the reason for the
out-of-order processing is. The packets do not have to have been
in the "wrong order" on the wire for out-of-order processing
to occur.

Similarly, the fact that MSN 17 invalidated STag 504 does not
guarantee that use of STag 504 in a tagged message that is
latter in the LLP stream will be flagged as an error. Invalidation
is only guaranteed by the time it is reported to the Data Sink ULP.




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


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