Subject: RE: [rddp] ddp architectural issue

From: "Garcia, Dave" <[email-masked]>
Date: Thu, 21 Nov 2002 10:37:17 -0800

Jerry,

You wrote: 
> This is not what I'm concerned about. I'm willing 
> to accept an added semantic to the existing 
> transports that once a buffer is posted to 
> receive data, its content may change regardless 
> of whether legitimate data have landed in the 
> buffer or not

> But my concern is with duplicate pkts. If DDP 
> placement happens before LLP processing, a dup 
> pkt may corrupt a buffer that has been delivered
> to ULP unless its Stag has been invalidated somehow.

> To prevent the above from happening I think some 
> minimal LLP processing is required, at least to 
> catch and discard dup pkts. Tom Talpey mentioned 
> to me a rule of no more than one update per buffer 
> needs to be enforced. Is that what people agree upon? 
> (I don't see it written down anywhere.) Also that 
> write-once rule may introduce a slew of other problems too.

The DDP spec has a requirement on the LLP that prevents
the type of duplicates you refer to. It's in the "Reliable 
Delivery LLP Requirements section:

11. The LLP MUST NOT pass a duplicate DDP Segment to 
    the DDP Layer after it has passed all the previous DDP 
    Segments to the DDP Layer and the associated ordering 
    information for the previous DDP Segments and the 
    current DDP Segment. 

You mentioned that this write-once rule may introduce
a slew of other problems. What might that be?

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

---

From: Jerry Chu <[email-masked]>
Date: Thu, 21 Nov 2002 01:39:49 -0800

Dave,

>    information for the previous DDP Segments and the 
Yes I saw that paragraph but failed to parse the sentences following
"after it ...".

>a slew of other problems. What might that be?
If a STag's scope (TBD) is defined by the RDMA layer or ULP, adding
a constraint such as a write-once rule to the STag by the LLP will likely
to interfere with the scope/semantics of the STag defined by the ULP.

An in-order, reliable LLP's job is to deliver each byte of data of the
same "sequence #", not the same "STag", exactly once.

Jerry