<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2722" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><FONT size=3><FONT face=Arial color=#0000ff 
size=2></FONT> </DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <BLOCKQUOTE class=cite cite="" type="cite">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.</FONT></BLOCKQUOTE>
  <DIV><BR>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.<BR><BR><BR><SPAN 
  class=625041022-15112005><FONT face=Arial color=#0000ff 
  size=2>[cait] </FONT></SPAN></DIV>
  <DIV><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN> </DIV></BLOCKQUOTE>
<DIV dir=ltr><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff 
size=2>I would agree that there isn't much point in defining a "reliable" 
datagram service unless it is more</FONT></SPAN></DIV>
<DIV dir=ltr><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff 
size=2>reliable than unreliable.</FONT></SPAN></DIV>
<DIV dir=ltr><SPAN class=625041022-15112005></SPAN> </DIV>
<DIV dir=ltr><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff 
size=2>To me that means that the the transport should deal with all networking 
problems other than a</FONT></SPAN></DIV>
<DIV dir=ltr><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff 
size=2>*total* failure to re-establish contact with the remote end. That 
makes it basically equivalent </FONT></SPAN></DIV>
<DIV dir=ltr><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff 
size=2>of a point-to-point Reliable Connection.</FONT></SPAN></DIV>
<DIV dir=ltr><SPAN class=625041022-15112005></SPAN> </DIV>
<DIV dir=ltr><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff 
size=2>The biggest difference, and justification, for having something 
like RDS is to eliminate point-to-point</FONT></SPAN></DIV>
<DIV dir=ltr><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff 
size=2>flow control and allow it to be replaced with ULP based flow control 
that is not point-to-point. The</FONT></SPAN></DIV>
<DIV dir=ltr><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff 
size=2>resources associated with tracking credits is where a lot of the overhead 
inherent in multiple</FONT></SPAN></DIV>
<DIV dir=ltr><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff 
size=2>point-to-point connections come from (that, and the synchronization of 
that data over the</FONT></SPAN></DIV>
<DIV dir=ltr><SPAN class=625041022-15112005><FONT face=Arial color=#0000ff 
size=2>network).</FONT></SPAN></DIV>
<DIV dir=ltr><SPAN class=625041022-15112005></SPAN> </DIV>
<DIV dir=ltr><SPAN class=625041022-15112005> </SPAN></DIV></BODY></HTML>