Re: DDP segment sequences for Untagged DDP message

On Jan 27, 2004, at 11:34 AM, Barry Reinhold wrote:

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

That is true, but understand that the only requirement is that the
LLP has *some* sequencing mechanism. DDP does not know what that
sequencing mechanism is, it only knows the original per-stream
order of DDP Segments.

Hence, for MPA/TCP the sequence number is a TCP stream position
(the offset of the last byte) but for SCTP it is a packet sequence
number (which for technical reasons is *not* the Stream Sequence
Number, but a number that behaves exactly as a Stream Sequence
Number *would* have had one been associated with an unordered chunk).

If you were to map DDP onto a different reliable transport you
might come up with a totally different method of sequencing packets,
but in actuality you probably never would and even if you did it
would match either byte numbering or packet numbering.

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

That information could be derived for SCTP, but in fact the function
described is handled by the TSN and TSN Ackpoint. That is because
SCTP manages acks for all streams in an association, and does not
ack them separately.

It would be more accurate to state that there is a point in a stream
where a packet and all prior packets have been completed. Even if
represented as a byte offset, as far as DDP is concerned a DDP Segment
was either completed or it was not. There is no such thing as "half
a segment" as far as it is concerned.

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

As pointed out above, stating these behaviors with proper abstraction
would probably cause more confusion than enlightenment. The draft 
authors
did a fine job of focusing on the services that the LLP provides to DDP,
and then trying to know as little about the LLP as possible.

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

Correct.

Although it might be more accurate to state that the delivery is of
a notice that a 200 byte untagged message has been received. The
bytes are not included in the notice.


> 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 receive completion for a 200 byte message *will* be received.

Depending on when Segment-2 is processed versus when the processing
of Segment-1 is done, you may/should get an invalid MSN error which
will terminate the connection.

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

If item 2 is received *before* item 1 has been completely processed
there will be no basis on which to reject the packet. The receiver
is not obligated to delay processing of item 2 because item 1 MIGHT
invalidate it.

A properly designed ULP will ensure that the meaning of each DDP Segment
is valid for placement no matter what subset of in-flight messages have
been placed before it -- that includes those sent afterwards.

While neither end will error check for dangerous buffer practices,
having the same byte targeted by multiple in-flight messages is
inherently non-determinstic.




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