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).
_______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
