RE: Some questions related to "last segment" of a ddp message

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 protected]]
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 protected] - http://asomi.com/
http://asomi.com/CaitlinBestlerPublicPgpKey.html


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