Subject: [rddp] Some questions related to "last segment" of a ddp message

From: "Barry Reinhold" <[email-masked]>
Date: Thu, 15 Jan 2004 16:37:01 -0500

Hemal,

I would like to check on a couple of issues:

I believe that it is possible to RECEIVE a sequence of DDP segments
using the untagged buffer model as follows: Let me know if this is not
correct.

Segment 1: QN=1, MSN=1, MO=200, L=0 (payload 100) (MO not 0 on first)
Segment 2: QN=1, MSN=1, MO=200, L=0 (payload 100) (duplicate)
Segment 3: QN=1, MSN=1, MO=100, L=0 (payload 100) (backward)
Segment 4: QN=1, MSN=1, MO=000, L=0 (payload 050) (meets 6.3, MO field)
Segment 5: QN=1, MSN=1, MO=400, L=1 (payload 000) (meets 6.1 L bit
field)

In particular, 
1. If no packets have been received w/ a given MSN and QN and a packet
arrives with a non-zero MO this is not an error.
2. The MO fields in intermediate segments are not constrained to be in
order, can have gaps, and can write over buffer space already written
to.

Or from a test perspective, if a receiver returned an error when
receiving the above sequence the receiver would be considered
non-conformant.

I am also a bit confused by the use of the term "last" in the draft.

If the above is considered a valid sequence it is unclear to me how the
receiver can meet the requirements of knowing that all DDP Segments of
the DDP message have been placed before it "delivers" the DDP message to
the ULP. (page 14 under L - Last flag, first bullet)

Is there some method other than the L bit that indicates that all
segments of a DDP message have been placed? (i.e. do implementations
need to keep a scoreboard?) The draft (in clause 7.4, first *, on page
20) references a requirement on the receiver to deliver only when the
last bit is set on the "last DDP Segment". How is the last segment
defined beyond the L bit?

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

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

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 15 Jan 2004 18:10:27 -0600

> Segment 2: QN=1, MSN=1, MO=200, L=0 (payload 100) (duplicate)

Overlapping (or duplicate) segments strike me as very suspect for the
following reasons:

a)	If there is any overlap in the segments of an untagged message
	there is no guarantee which placement will occur last. Hence
	there can be no benefit to sending two segments covering the
	same bytes within an untagged message.
b)	It is clear that an untagged message SHOULD be broken into
	ascending segments, each the maximum size allowed. There may
	be valid reasons for alternate segmenting schemes, but one
	that produces no reliable results cannot possibly be a valid
	justification for overriding a "SHOULD".

This does NOT imply that the receiver should be checking for overlaps,
merely that there is no reason to take heroic efforts to deal with
problems caused by overlaps.

> Segment 3: QN=1, MSN=1, MO=100, L=0 (payload 100) (backward)

Segments SHOULD be sent in ascending order (a non-requirement that
I opposed). As a sender you should only do this if you have a valid
reason that optimizes something.

As a receiver, of course, you have to presume that the sender had
a valid reason. More importantly, if you are optimized to process
segments out-of-order you will never even notice that it happened.

> order, can have gaps, and can write over buffer space already written

Gaps are not explicitly forbidden. But it is important to
understand that the result will be non-determinant bytes
in the target buffer, NOT unmodified bytes.

For an unordered receiver, this is all irrelevant. The simplest
implementation is to simply place all non-terminal segments,
set the length from the segment with the L bit set, and assume
that the entire message was delivered when the final segment
is eligible for delivery.

Remember that the receiver is allowed to (perhaps expected to)
process segments in the order they arrive, which is not necessarily
their order in the LLP stream.

Note: as a security issue, implementations SHOULD ensure that
"non-determinant" bytes are not actually bytes holding values
once held by buffers used in another process. This is only a
factor if intermediate buffering is used for reasons relating
to optimizing cache flushes.

> receiving the above sequence the receiver would be considered

Correct. A receiver has no business trying to diagnose this type
of behavior in real-time.

> I am also a bit confused by the use of the term "last" in the draft.
The "Last" segment in LLP sequence must have the highest MO. But as
your example points out, this can be cheated with a zero length message.

> the ULP. (page 14 under L - Last flag, first bullet)

For any DDP segment, the DDP layer is expected to determine whether
all prior DDP segments (in LLP stream sequence) have been placed
and delivered before it can be delivered.

Even if the "last" segment is not yet deliverable, its contents
can be placed, and the message length can be noted for later delivery.

> defined beyond the L bit?

The last segment has three characteristics:
	1)	L bit set.
	2)	Highest LLP Sequence
	3)	Highest MO within the message

If all DDP Segments for the LLP Stream have been placed, the receiver
may assume that all prior segments for this message have been placed.
The fact that the "last" DDP Segment must have the highest sequence
in the LLP Stream allows the receiver to make this assumption without
keeping a scoreboard. It is NOT something that the receiver should
be attempting to enforce.

-- 
Caitlin Bestler - [email-masked] - http://asomi.com/
http://asomi.com/CaitlinBestlerPublicPgpKey.html

---

From: "Michael C. Cambria" <[email-masked]>
Date: Fri, 16 Jan 2004 09:38:57 -0500

> order, can have gaps, and can write over buffer space already written

My understanding is yes, yes and (re write over buffer space) not convinced.

On pg 20 of draft-ietf-rddp-ddp-01.txt, "For an Untagged DDP Message, 
the combination of the QN and MSN uniquely identifies a DDP Message." 
Since an MSN doesn't make sense for a DDP _message_, I've read this to 
mean that QN & MSN uniquely identifies a DDP _segment_.

So the way I read the draft, I can't find text that says one cannot send 
overlapping DDP segments.

> receiving the above sequence the receiver would be considered

I'd return an error for several reasons.

1) I know of no legal untagged message on QN=1 that has a payload as 
large as you describe.

2) Where are payload bytes 50-99?  300-399?

If I understand the example correctly, segment 4 provides DDP/RDMA 
message bytes 0-49; segment 3 provides 100-199, segments 1 & 2 provide 
200-300

MikeC