Subject: Re: Cisco SG16: Transaction ID uniqueness

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 4 Feb 2000 17:17:37 -0500

Acks are a function of transport.  The ACK syntax we have is UDP only.
You can't, in general, require an ACK, immediate or not.
We could, theoretically, change Annex D to do what you ask, but we couldn't
change the main body of the text.  Given that, what would you want to do?

I'd rather leave it as it is right now, and get some experience.

Brian

-----Original Message-----
From: Flemming Andreasen [mailto:[email-masked]]
Sent: Friday, February 04, 2000 4:39 PM
To: [email-masked]
Subject: Re: Cisco SG16: Transaction ID uniqueness

Hi Brian

Please look for FSA below (mail reader acting up here so sorry about the
formatting)

-- Flemming

"Rosen, Brian" wrote:
===============
Since there is no way for the requestor to know how long the responder will
take,
how long should it wait before sending a duplicate request, after it gets a
pend?

Whatever the answer is, that is the rate at which pends have to come.

If the timer is very long, then the timer to clear a missed final response
will be very long

FSA: No. You make sure the final response is transmitted reliably by
requiring it to be acknowledged.

Whatever the timer is, we may have to have repeated pends, and each of them
will be proceeded by a duplicate request in your proposal.

FSA: Correct

The scheme we have now is just like the one you propose, except that the
pends
come without prompt by the requestor, and the default value of the timer is
short.

FSA: No it's not. With my proposal, I can safely set the timer to say 30
seconds, and still detect a lost final response promptly. If I do anything
of the sort with your proposal, it will be a looooong time before we
recover.

Brian

---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 4 Feb 2000 17:40:20 -0500

Fair enough. Given that, I would prefer changing Annex D.

-- Flemming

"Rosen, Brian" wrote:

>  Acks are a function of transport.  The ACK syntax we have is UDP
> only.You can't, in general, require an ACK, immediate or not.We could,
> theoretically, change Annex D to do what you ask, but we
> couldn'tchange the main body of the text.  Given that, what would you
> want to do?I'd rather leave it as it is right now, and get some
> experience.Brian
>
>      Please look for FSA below (mail reader acting up here so
>      sorry about the formatting)
>
>      -- Flemming
>
>
>      "Rosen, Brian" wrote:
>      ===============
>      Since there is no way for the requestor to know how long the
>      responder will take,
>      how long should it wait before sending a duplicate request,
>      after it gets a pend?
>
>      If the timer is very long, then the timer to clear a missed
>      final response will be very long
>
>
>      FSA: No. You make sure the final response is transmitted
>      reliably by requiring it to be acknowledged.
>
>      The scheme we have now is just like the one you propose,
>      except that the pends
>      come without prompt by the requestor, and the default value
>      of the timer is short.
>
>      FSA: No it's not. With my proposal, I can safely set the
>      timer to say 30 seconds, and still detect a lost final
>      response promptly. If I do anything of the sort with your
>      proposal, it will be a looooong time before we recover.
>
>      Brian
>
--