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

From: "Culley, Paul" <[email-masked]>
Date: Tue, 27 Jan 2004 08:01:34 -0600

Note: this is the second sending, it did not show after the first time
within 24 hours...

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, if they were merely
received in this order (they got flipped in route and were received out
of order, but sent in order), then the result would be a normal
delivery.

I am not certain I agree with Pat on the "optional" nature of checking
for errors that are not even mentioned in the specification.  I think
that if we have to list all of the checks that we DO NOT perform in the
specifications, then we have quite a bit of writing left to do.

That said, we should perhaps be a bit more clear about the rules on
Sending overlapped segments, or Sending Gaps.  I am definitely not in
favor of requiring the receiver to check for either case.  If we were to
add text to DDP for this I think it would say something like:

When sending an Untagged Message, the Sender MUST send data to each
offset within the target buffer only one time.

When sending an Untagged Message, the Sender MUST send a contiguous
stream of bytes to the destination buffer, starting at offset 0.

In my mind, we should allow the receiver to check for these conditions
only if these rules are made on the sender.

Paul R. Culley
HP Fellow
281-514-5543

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

My responses are marked pat

-----Original Message-----
From: Culley, Paul [mailto:[email-masked]]
Sent: Friday, January 16, 2004 12:28 PM
To: Barry Reinhold; RDDP
Subject: RE: [rddp] DDP segment sequences for Untagged DDP message

Below...

Paul R. Culley
HP Fellow
281-514-5543

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Barry Reinhold
Sent: Friday, January 16, 2004 1:09 PM
To: RDDP
Subject: [rddp] DDP segment sequences for Untagged DDP message

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
[prc] yes
[pat]DDP message (bytes 0-200) occurs after 1.
     2 will cause an invalid MSN error

1. QN = 0, MSN = 1, MO = 100, L = 0, Payload = 100 bytes
2. QN = 0, MSN = 1, MO = 0,   L = 1, Payload = 100 bytes
Result: ULP sent Error type=Untagged Buffer Error, Error Code=Invalid MO
[prc] No, the receiver will place both segments, but inform the ULP that
only 100 bytes was delivered, ending at MO=99.  No error should be
detected or reported, unless the receiver's buffer was not large enough
to hold the second 100 bytes. [pat] Checking for the error of last
segment not containing highest MO is optional. Both behaviors above
would be valid responses.

1. QN = 0, MSN = 1, MO = 0, L = 0, Payload = 100 bytes
2. QN = 0, MSN = 1, MO = 0, L = 1, Payload = 100 bytes
Result: DDP Message (bytes 0-100) is delivered to ULP
[prc] yes, but it is not certain which segment ends up in the buffer, it
won't matter unless the two payloads are different. [pat] agree. 

1. QN = 0, MSN = 1, MO = 000, L = 0, Payload = 100 bytes
2. QN = 0, MSN = 1, MO = 200, L = 1, Payload = 100 bytes
Result: DDP Message (bytes 0-300) is delivered to ULP
[prc] yes, but the middle 100 will contain unknown values (probably what
they had before the buffer went through DDP). [pat] There are two valid
behaviors. The receiver may deliver the message as above or it may be
checking and report an error.

1. QN = 0, MSN = 1, MO = 300, L = 1, Payload = 100 bytes
Result: DDP Message (bytes 0-400) is delivered to ULP
(This is based on wording in 6.3, MO field. Note that the second
sentence simply says that the MO "that references the first octet MUST
be set to zero", not that a segment having a zero MO is required) [prc]
yes, but first 300 is unknown [pat] Again the receiver is allowed to
deliver or to report an error.

1. QN = 0, MSN = 1, MO = 100, L = 0, Payload = 100 bytes
2. QN = 0, MSN = 1, MO = 000, L = 1, Payload = 0 bytes
Result: ULP sent Error type=Untagged Buffer Error, Error Code = Invalid
MO (There is ambiguity between 6.1 L bit field description ( Segment w/
L bit set must have highest MO), and 9.1 (implies that for non-zero
length segments the header fields are not validated.) [prc] no, at least
not because of a protocol error.  There is only an error if the buffer
limits as defined by the ULP is exceeded.  You should get an indication
that a zero length message was delivered. [pat] The ambiguity you point
out is probably an error. The MUST on checking Untagged DDP segments
required that they be validated before placement. A zero length segment
isn't placed so the MUST didn't apply to it. There probably should be a
statement about checking the fields before delivery of zero length
untagged messages or zero length segments with the L bit set. Also even
if that statement is added, this is another case where the receiver is
allowed to deliver or report an error.

1. QN = 0, MSN = 1, MO = 000, L = 0, Payload = 100 bytes
2. QN = 0, MSN = 1, MO = 100, L = 1, Payload = 0 bytes
Result: DDP Message (bytes 0 - 100) is delivered to ULP
[prc] yes
[pat] yes. Note that this is another case where there should be a
requirement that the zero length segment header values be checked before
delivery.

1. QN = 0, MSN = 1, MO = 100, L = 1, Payload = 0 bytes
Result: DDP Message (bytes 0 - 100) id delivered to ULP. 
[prc], yes, but with unknown data values.
[pat] May deliver the message or may scoreboard and report an error.

Barry Reinhold
Lamprey Networks
[email-masked]
(603) 868-8411

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

_______________________________________________
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: Caitlin Bestler <[email-masked]>
Date: Tue, 27 Jan 2004 08:59:22 -0600

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

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

---

From: "Barry Reinhold" <[email-masked]>
Date: Tue, 27 Jan 2004 12:34:30 -0500

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-masked] [mailto:[email-masked]] 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

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 27 Jan 2004 13:28:50 -0600

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

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

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.

> indicates that all octets in the LLP stream up to the value indicated

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.

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

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

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

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