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

Paul,

RE: 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]

The receiver is not required to check for overlaps and holes but there isn't anyplace that disallows it doing so. I believe that this was our intent when we wrote it and it is consistant with the text in the draft - 7.2 says at the end that the Data Sink is not required to verify that the entire message has been received. It doesn't prohibit checking. 

So it would be valid behavior to detect an error because of the missing bytes. It would also be valid behavior to not detect that error.

Pat


-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of
Culley, Paul
Sent: Friday, January 16, 2004 7:33 AM
To: Michael C. Cambria; RDDP
Cc: Barry Reinhold
Subject: RE: [rddp] Some questions related to "last segment" of a ddp
message


A couple of points are included below...

Paul R. Culley
HP Fellow
281-514-5543


-----Original Message-----
From: [email protected] [mailto:[email protected]] 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 protected]
https://www1.ietf.org/mailman/listinfo/rddp

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