Subject: [rddp] Clarification on DDP segmentation

From: "Larsen, Roy K" <[email-masked]>
Date: Thu, 10 Oct 2002 12:35:47 -0700

The draft is ambiguous as to whether the DDP layer may send DDP message
segments out of order to the LLP.  The draft does explicitly deal with OOO
segments on receive but only as it applies to a "rototilled" implementation
with the implication being that reordering has been done by the fabric.
However, in describing the Last Flag bit in section 6.1, the sentence:

"The DDP Segment with the L bit set to 1 MUST be posted to the LLP after all
other DDP Segments...."

This implies that DDP may send segments OOO to the LLP.  In any case, I
would like to see one of the following statements added to section 7.2:

"The Data Source MUST deliver segments of a DDP message to the LLP in
order."

or

"The Data Source MAY deliver segments of a DDP message to the LLP in any
order with the exception of the DDP segment with the L bit set which MUST be
the last segment sent to the LLP."

Non-rototilled implementations (particularly hybrid RNIC solutions) can take
advantage of an in-order DDP segment semantic so it is important that the
draft be clear on this subject.

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

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 10 Oct 2002 16:25:47 -0500

On 10/10/02, Larsen, Roy K wrote:

>The draft is ambiguous as to whether the DDP layer may
>send DDP message segments out of order to the LLP.  The
>draft does explicitly deal with OOO segments on receive
>but only as it applies to a "rototilled" implementation
>with the implication being that reordering has been done
>by the fabric. However, in describing the Last Flag bit in
>section 6.1, the sentence:
>
>"The DDP Segment with the L bit set to 1 MUST be posted to
>the LLP after all other DDP Segments...."
>
>This implies that DDP may send segments OOO to the LLP. 
>In any case, I would like to see one of the following
>statements added to section 7.2:
>
>"The Data Source MUST deliver segments of a DDP message to
>the LLP in order."
>
>or
>
>"The Data Source MAY deliver segments of a DDP message to
>the LLP in any order with the exception of the DDP segment
>with the L bit set which MUST be the last segment sent to
>the LLP."
>
>Non-rototilled implementations (particularly hybrid RNIC
>solutions) can take advantage of an in-order DDP segment
>semantic so it is important that the draft be clear on
>this subject.
>
>Roy

The phrase "in order" here begs the question. Normally, 
DDP segment ordering is *defined* by the order in which
they were presented to the LLP.

If you want to specify the first option, it would probably
make more sense to require that the Message Offsets (MO)
must increase with each segment.

The draft already requires that the entire message be
delivered. About the only other possible requirement
would be to mandate that each byte of the message be
placed in *exactly* one DDP segment (as opposed to
at least one).

It shouldn't make a difference to the Data Sink anyway.
If its checking the offsets on successive messages then
its wasting cycles. There is a valid reason why the highest
offset must be in the last segment, it makes calculation
of the message size very simple.

The only benefit I can think of for mandating the others 
to be in sort ascending order is to make things easier
for packet sniffers.

But I agree, it might be nice to highlight that warning
so that nobody builds an RNIC that rejects out-of-order
segments that were otherwise valid. Requiring that they
be sent in order is also equally valid. Unlike tagged
messages, there is no need to generate untagged message
segments out of order.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp