RE: DDP segment sequences for Untagged DDP message

Pat,
	Good catch -- your understanding of LLPSegNumCompleted is what I
intended. Case 2 is incorrect, but you provided the information I was
looking for anyways.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Tuesday, January 27, 2004 7:49 PM
To: [email protected]; [email protected]; [email protected];
[email protected]
Subject: RE: [rddp] DDP segment sequences for Untagged DDP message

Barry,

In case 1, the transmitter sent the segments to the LLP in the correct
order and they got misordered on the way to the receiver. As you stated,
no errors occurred and the correct behavior is to deliver the message
with a length of 200 octets.

By the way, I think you meant that LLPSeqNumCompleted indicates that all
octets in the LLP stream up to that point have been transfered to DDP.
The LLP doesn't do placement - DDP does placement. Therefore, the LLP
can't maintain a value indicating which octets in the stream have been
placed. I also am assuming that when you mention your new terms,
Seq=Seg.

I don't understand your case 2. If I understand LLPSeqNumCompleted, it
indicates how much of the LLP data stream has been completely received
(that is, the point to which there are no gaps due to out of order
arrival). Therefore, it should increase with time - it can never
decrease. In case 2 below it decreases so either I don't understand
LLPSeqNumCompleted or there is a typo in the example. Also note that
item 11 in section 5 Reliable Deliver LLP Requirements is that the LLP
MUST NOT pass a duplicate DDP segment to DDP after it has passed all
previous segments to DDP. This requirement means that LLPSeqNumTag MUST
always be greater then the previous value of LLPSeqNumCompleted.

You said that this was the case where the transmitter violated sending
the last segment last. In that case, the segment in 2 would have a
higher sequence number than the segment in 1 so perhaps you meant:

Case 2b
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 =
700, LLPSegNumTag = 700

In that case I agree that:
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)

I almost agree with your next statement:
The ONLY correct behavior on reception of item 2 is to send the ULP the
error (0x03 - invalid MSN - MSN range is not valid)

There is the issue that Caitlin pointed out. It is possible that there
is a window in a DDP implementation where it has received segment 1 and
is still munching on it (hasn't advanced the MSN range yet) while
segment 2 comes in and gets placed. In that case, segment 2 could come
in and get placed without an error being detected. This would be similar
to the behavior that could occur if segment 2 arrived out of order
before segment 1. 

The ambiguous window should be over before the Untagged Message is
delivered to the ULP because DDP should ensure that it doesn't touch the
buffer once it has delivered it. So, if MSN 1 was delivered before 2
arrived, then 2 should cause the invalid MSN error.

Regards,
Pat

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of Barry
Reinhold
Sent: Tuesday, January 27, 2004 9:35 AM
To: 'Caitlin Bestler'; 'Paul Culley'; 'RDDP'
Subject: RE: [rddp] 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


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


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