NRR is a non-repudiation function. It is not intended as a transmission
error detector. Someone will have to make a convincing case that TCP is
not sufficient for detecting transmission errors.
Regards,
Marty
*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown
Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************
David Fischer <> on 09/19/2001 10:46:21 AM
To:
Dan Weinreb <>
cc:
Subject: RE: T2 Retry with Delivery Receipt
Very good. I agree with most of it.
One comment about check-sums. We already have an transmission
error-catching
mechanism called NRR.
On the whole, I think this is very good. The point is that there are some
scenarios which would require a retry. But I prefer to phrase the question
differently -- why would an IM *ever* stop a retry from the end? It is not
the
job of an IM to tell the ends what they may or may not send. Since it is
an
easy thing to differentiate between an IM retry and an end retry, its not
"why
would we" but rather "why wouldn't we"?
This may all be moot since built-in problems with multi-hop (like not
allowing
end-to-end retries) could force IMs out of the picture. I'd rather not,
but . .
. ?
Regards,
David Fischer
Drummond Group.
