Subject: RE: [rddp] DDP: Ordering Among DDP Messages (7.3) Data Source rul es

From: "Larsen, Roy K" <[email-masked]>
Date: Tue, 5 Nov 2002 12:24:28 -0800

Caitlin,

But error checking is the point.  The protocol specification must state what
the legal possibilities are so an implementation doesn't add extraneous
error checking.  Or worse yet, make assumptions about ordering because the
specification is silent on the subject.

I would much rather see the SHOULD changed to MAY.  I don't want to limit
implementation choices but I do want to know what combinations I need to
deal with.  This is true for segments within a ULP message and interleaving
of segments between messages that preserve 'L' segment order.

Please keep in mind that the DDP protocol must be valid when run on top of a
non-rototilled TCP implementation.  In these cases, DDP PDU will be received
as a byte stream.  Knowing the allowable ordering of that byte stream will
affect implementation.

Roy 

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]]
Sent: Tuesday, November 05, 2002 11:33 AM
To: [email-masked]
Subject: [rddp] DDP: Ordering Among DDP Messages (7.3) Data Source rules

The following rule was added:

> At the Data Source, DDP:
>
> ...
> 
> * SHOULD transmit DDP Segments within a DDP Message in
> increasing MO order for Untagged DDP Messages and in
> increasing TO order for Tagged DDP Messages.

I believe this topic was thoroughly discussed, and that was
NOT the consensus. While it may seem innocuous, I do not
believe that a SHOULD clause is appropriate when there are
known valid reasons for at least some implementations not to
do so.

Further, in this case, there is absolutely no benefit to
this clause. It will only encourage sloppy implementations
to add extraneous "error checking" code looking for
"incorrectly" sequences segments.

As previously covered, a simple compliant receiver will not
even *notice* when segments are not in a natural order. It
has no *need* to examine their relative offsets at all.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
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, 5 Nov 2002 15:24:36 -0600

On 11/5/02, Larsen, Roy K wrote:

>Caitlin,
>
>But error checking is the point.  The protocol
>specification must state what the legal possibilities are
>so an implementation doesn't add extraneous error
>checking.  Or worse yet, make assumptions about ordering
>because the specification is silent on the subject.
>
There is no error to be checked, unless you think that
ascending offsets somehow provides signifigant error
detection beyound the CRC-32.

The receiver has no need to carry any expectation about the
relative ordering of any offset within a message other than
that the one marked with the L bit will be last. That
restriction allows the receiver to determine the logical
size of an anonymous buffer without having had to tally it
as it arrived.

Specification silence SHOULD imply lack of any restrictions,
but it may be advisable to add that the receiver MUST NOT
make any assumptions about the ordering of segments within
a message other than the requirement that the last one be
labeled as such and have the highest message offset.

>I would much rather see the SHOULD changed to MAY.  I
>don't want to limit implementation choices but I do want
>to know what combinations I need to deal with.  This is
>true for segments within a ULP message and interleaving of
>segments between messages that preserve 'L' segment order.
>
>Please keep in mind that the DDP protocol must be valid
>when run on top of a non-rototilled TCP implementation. 
>In these cases, DDP PDU will be received as a byte stream.
> Knowing the allowable ordering of that byte stream will
>affect implementation.
>
Even when cleanly layered, the DDP receiver has no need to
track the history of message offsets within a message. If it
expects nothing it will handle all valid messages, and
consume zero gates and zero cycles doing so.

Caitlin Bestler