Re: T2 Retry with Delivery Receipt

From
System
Date
2001-09-19T11:09:00+00:00
ID
Thread
Re: T2 Retry with Delivery Receipt
Date: Wed, 19 Sep 2001 09:46:21 -0500
From: "David Fischer" <>

Very good.  I agree with most of it.

Thank you.

One comment about check-sums.  We already have an transmission error-catching

mechanism called NRR.

Yes, but it has several drawbacks as an error-catching mechanism.
First, it's optional.  Second, the error isn't detected until after
the receiver might have processed the message.

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"?

Of course an IM should never stop an end-to-end retry; of course if
the protocol allows for end-to-end retry, there would be an easy and
well-defined way to differentiate.  The proposed "retry count" is one
way to do it.