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

From: "Culley, Paul" <[email-masked]>
Date: Fri, 16 Jan 2004 09:32:58 -0600

A couple of points are included below...

Paul R. Culley
HP Fellow
281-514-5543

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael C. Cambria
Sent: Friday, January 16, 2004 8:39 AM
To: RDDP
Cc: Barry Reinhold
Subject: Re: [rddp] Some questions related to "last segment" of a ddp
message

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

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_.
[prc] I suspect some misunderstanding here.  An MSN (Message Sequence
Number)
specifically identifies which _message_ on the particular Queue the
segment
belongs to.  Think of a queue with 5 2000 byte buffers, If TCP can
manage 
1500 bytes or so per segment, each buffer can hold two segments.  The
two segments for the second buffer might be identified by QN=1, MSN=2,
MO=0, L=1500 and QN=1, MSN=2, MO=1500, L=500.  The two segments have the
same MSN, so your statement is not correct.
[prc]

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

overlapping DDP segments.

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

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.
[prc] for DDP, all QN values are legal, and only the ULP can place
limits on their size, what you say is true only if you are using RDMA as
the next up ULP. [prc]

2) Where are payload bytes 50-99?  300-399?
[prc] The receiver is not expected to check for overlaps, or holes in
the data.  So this is not a valid reason to report errors and there are
no defined errors for this.  Perhaps the draft should explicitly say not
to report errors for these cases.  As long as all the  transmitter's
data was placed and delivered, the receiver is compliant.  In the case
of overlaps, the receiver is not even required to make sure that the
highest TCP sequence numbered segment was the last placed, so overlaps
could lead to unpredictable delivered data.  As a consequence of this,
the transmitter SHOULD send data with no overlaps or holes, although an
application could conceivably be designed to work even if this is not
followed (some kind of test suite?).
[prc]
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

[prc] one last comment; segment 5 (with zero length) is legal, and must
be delivered.  Further, even if no other data for the message arrived,
the zero length message does consume an untagged buffer.
[prc]

MikeC

_______________________________________________
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: "Michael C. Cambria" <[email-masked]>
Date: Fri, 16 Jan 2004 11:46:56 -0500

> A couple of points are included below...

I was confused.  I understand what you describe above, but read more 
into it (e.g. applying to uniquely identify a DDP segment as well). 
Until know, I didn't think overlaps were possible.

Thanks,
MikeC

> overlapping DDP segments.

This should have been "the way the draft reads".  My reading (which is 
incorrect) ruled out overlaps.

Thanks,
MikeC

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 16 Jan 2004 11:23:56 -0600

> incorrect) ruled out overlaps.

To be precise, there are two distinct issues. Can a sender create
overlapping segments within a message, and whether the receiver
is under any obligation to check for this.

 From the sender's perspective, the TO SHOULD be in ascending
order and segmentation SHOULD be based upon the PMTU. Shifting
from the obvious segmentation strategy is legal, but only if
the sender has a valid reason for doing so. Given that overlapped
messages does not produce a predictable result there can be no
valid reason for doing this.

On the receiving end, this is something that the receiver
SHOULD NOT be checking.