[openib-general] [ANNOUNCE] Contribute RDS(ReliableDatagramSockets) to OpenIB

[Caitlin Bestler]

		In absence of any protocol level ack (and regardless of
protocol level ack), it is the application which has to implement its
own reliability. RDS becomes a passive channel passing packet back and
forth including duplicate packets. The responsibility then shifts to the
application to figure out what is missing, duplicate's etc.


	This would seem at odds with earlier assertions that as long as
there were another path to the endnode, RDS would transparently recover
on behalf of the application.  I thought Oracle stated for their
application that send failure would be interpreted as endnode failure
and cast out the peer - perhaps I misread their usage model.  Other
applications who might want to use RDS could be designed to deal with
the associated faults but if one has to deal with recovery / resync at
the application layer, then that is quite a bit of work to perform in
every application and is again at odds with the purpose of RDS which is
to move reliability to the interconnect to the extent possible and to
RDS so that the UDP application does not need to take on this complex
code and attempt to get it right.
	
	
	[cait] 
	 

I would agree that there isn't much point in defining a "reliable"
datagram service unless it is more
reliable than unreliable.
 
To me that means that the the transport should deal with all networking
problems other than a
*total* failure to re-establish contact with the remote end. That makes
it basically equivalent 
of a point-to-point Reliable Connection.
 
The biggest difference, and justification, for having something like RDS
is to eliminate point-to-point
flow control and allow it to be replaced with ULP based flow control
that is not point-to-point. The
resources associated with tracking credits is where a lot of the
overhead inherent in multiple
point-to-point connections come from (that, and the synchronization of
that data over the
network).
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20051115/d6e476f0/attachment.html>