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

From: [email-masked]
Date: Fri, 23 Jan 2004 14:07:30 -0700

Caitlin,

I don't see any "SHOULD" in the draft regarding sending the segments into ascending order. Are you suggesting that there should be a SHOULD or is there a SHOULD I am missing?

I'm also not sure there is a technical reason that justifies such a SHOULD. It would make scoreboarding (for a receiver that wants to add extra error checking) during in-order delivery easier but that doesn't seem to be a strong enough reason for a SHOULD especially since the receiver would have to deal with cases where the transmitter wasn't following the SHOULD.

On overlapping - as long as the overlapped data is the same in both segments, placement order of overlapping segments doesn't matter. Message content had better not be changing while the message is being transmitted anyway because that could cause problems even if there was no overlapping. I can't see where overlapping gains anything and it is wasteful of bandwidth so I don't have much problem with a SHOULD NOT or MUST NOT, but I don't see much benefit to them either. 

Regards,
Pat

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]]
Sent: Thursday, January 15, 2004 4:10 PM
To: Barry Reinhold
Cc: Hemal Shah; RDDP
Subject: Re: [rddp] Some questions related to "last segment" of a ddp
message

On Jan 15, 2004, at 3:37 PM, Barry Reinhold wrote:

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

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.

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

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.

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

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.

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

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.

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

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

_______________________________________________
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: Fri, 23 Jan 2004 16:01:56 -0600

On Jan 23, 2004, at 3:07 PM, <[email-masked]> wrote:

> Caitlin,
>
> I don't see any "SHOULD" in the draft regarding sending the segments 
> into
> ascending order. Are you suggesting that there should be a SHOULD or is
> there a SHOULD I am missing?

DDP section 7.3 ("Ordering Among DDP Messages") specifies:

    At the Data Source, DDP:

      * MUST transmit DDP Messages in the order they were submitted to
         the DDP layer,

      * 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'm also not sure there is a technical reason that justifies such a 
> SHOULD.
> It would make scoreboarding (for a receiver that wants to add extra 
> error
> checking) during in-order delivery easier but that doesn't seem to be a
> strong enough reason for a SHOULD especially since the receiver would 
> have
> to deal with cases where the transmitter wasn't following the SHOULD.

More it importantly, it MAY deal with out-of-order delivery. You could
even argue that it SHOULD NOT insist of processing segments in order if
doing so increases the utilization of host memory (that is, processing
in order SHOULD only be done if the re-ordering is done without extra
usage of host memory).

If you scan the archives you'll find a prolonged discussion on this 
point.
I believe the alleged justification was essentially that it would 
optimize
handling of complex scatter-gather-lists. That never struck me as a 
valid
argument, and further making it a SHOULD negated any benefit that there
might have been and only acted to discourage known valid optimizations.

A "SHOULD" that has *common* valid reasons for being overridden is
essentially a "nop".

My opinion remains that the "SHOULD" clause ought to be removed, but
it really doesn't have any negative impact.

>
> On overlapping - as long as the overlapped data is the same in both 
> segments,
> placement order of overlapping segments doesn't matter. Message 
> content had
> better not be changing while the message is being transmitted anyway 
> because
> that could cause problems even if there was no overlapping. I can't 
> see where
> overlapping gains anything and it is wasteful of bandwidth so I don't 
> have
> much problem with a SHOULD NOT or MUST NOT, but I don't see much 
> benefit to
> them either.
>

Agreed. The key here is that segmentation of untagged messages is not
supposed to be under ULP control, and there is absolutely no way to
justify a bandwidth-wasting algorithm at the DDP layer.

 From the point of view of the receiver, I agree that they are completely
unworthy of run-time testing no matter how close to zero the cost is.