Subject: RE: [rddp] comments on draft-black-rdma-concerns-00.txt

From: "Culley, Paul" <[email-masked]>
Date: Tue, 30 Jul 2002 08:59:47 -0500

It seems that the case you bring up should not be allowed in a good implementation.  Once the data is "delivered" to the application (step 2, allowing step 4 to take place), the implementation should not allow duplicate packets to have any effect.  I believe that reliable transports like TCP and SCTP have this semantic, it is very unclear to me that an unreliable transport should be used by an application that wants to treat the data as you suggest.

Paul Culley
HP Sr. Fellow
281-514-5543

-----Original Message-----
From: Bill Sommerfeld [mailto:[email-masked]]
Sent: Tuesday, July 30, 2002 2:17 AM
To: H.K. Jerry Chu
Cc: [email-masked]; [email-masked]
Subject: Re: [rddp] comments on draft-black-rdma-concerns-00.txt 

> In other environment and/or application paradigm where attacks
> are not an issue, implementations may choose to defer tag
> invalidation or reuse/remap tags in order to attain higher
> performance. These different levels of protection can be
> negotiated upfront.

So, in thinking further about this, maliciousness is not actually
required for overwrites to be problematic.

Next hypothetical:

Remember that IP networks may duplicate packets.  

1) application receives packet using DDP
2) application gets notified that data is available.
3) application believes it is in a safe and trusting environment, so
RDDP mapping remains valid (neither explicit invalidation nor implicit
invalidate-on-rx takes place)
4) application modifies received data in place
5) duplicate packet arrives, overwriting buffer.
6) application does some processing which depends on data not
being overwritten after (4)

						- Bill

_______________________________________________
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: Tue, 30 Jul 2002 09:22:11 -0500

On 7/30/02, Culley, Paul wrote:

>It seems that the case you bring up should not be allowed
>in a good implementation. Once the data is "delivered" to
>the application (step 2, allowing step 4 to take place),
>the implementation should not allow duplicate packets to
>have any effect.  I believe that reliable transports like
>TCP and SCTP have this semantic, it is very unclear to me
>that an unreliable transport should be used by an
>application that wants to treat the data as you suggest.
>
>Paul Culley
>HP Sr. Fellow
>281-514-5543
>

I would upgrade that from "good implementation" to "valid
implementation". IMHO, RDDP is only valid over two delivery
semantics: exactly-once deliver (reliable), and at-most-once
delivery (unreliable).

I believe prior disucssions have clearly established that
exactly-once delivery is a requirement of the underlying
tranwsport.

The semantics of unreliable delivery have been debated,
especially between Steph and myself. I favor a
"transactional exchange" model where a sequence of RDMA
Writes and the terminating SEND are reported to the Data
Sink ULP as a success only if the entire set is received.
Steph has advocated more of a "hands off" approach where the
transport does as little as possible in unreliable mode, and
expects the ULP to sort everything out (presumably on the
theory that it was the ULP was the troublemaker that
insisted on using an Unreliable mode in the first place). 

In either case, without at-most-once delivery semantics
there is no way to provide meaningful ordering of tagged
puts and notifiable untagged puts. Inherent to the entire
RDMA paradigm is that completion of an anonymous receive
implies reception of prior RDMA writes.

IMHO, if each RDMA write received must be reported to the
ULP then you are no longer truly RDMA. The difference for
"unreliable" RDDP is that exchange N can succeed even if
exchange N-1 failed.

Caitlin Bestler
http://www.asomi.com/CaitlinBestler.html