Subject: FW: Cisco SG16: Provisional Response timers

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 3 Feb 2000 19:06:42 -0500

Resend.

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B904:EXCH]
> Sent: Thursday, February 03, 2000 2:43 PM
> To:   'Chip Sharp'; [email-masked]
> Subject:      RE: Cisco SG16: Provisional Response timers
>
> This looks like a v2 optimization.  Anyone else care to comment?
>
> -----Original Message-----
> From: Chip Sharp [SMTP:[email-masked]]
> Sent: Tuesday, January 25, 2000 7:51 PM
> To:   [email-masked]
> Subject:      Cisco SG16: Provisional Response timers
>
> Section:        D.1.4
> Category:       Technical
> Issue:          The draft text specifies that receipt of a provisional
> response
> will imply a switch to a longer repetition timer for the transaction.
> However, there is no other reliability mechanism in place to detect the
> loss of the final response for that transaction, and consequently a lost
> final response may not be detected for a while (depends on the longer
> repetition timer). This leads to suboptimal behaviour of the protocol with
> unnecessary long time-outs.
> Proposal:       It is proposed, that a final response issued after a
> provisional
> response requires an immediate confirmation to enable rapid detection of a
> lost final response. Since the provisional response itself may be lost,
> this implies that the final response should include an indication that a
> response acknowledgement is required (immediately).
>
> v13 Status:     OPEN. No relevant text changed.
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------

---

From: Chip Sharp <[email-masked]>
Date: Fri, 4 Feb 2000 00:09:46 -0500

> > This looks like a v2 optimization.  Anyone else care to comment?

An optimization ? Well, if you insist, but if you are serious about targeting
the carrier market with this protocol, I quite frankly don't see how you can
skip these kinds of "optimizations". After all, we do want the protocol to
perform well, right ?

 > > Subject:      Cisco SG16: Provisional Response timers

This one seems to belong here as well:

Section:         8.2.3 (TransactionPending), last paragraph
Category:      Technical, Editorial
Issue no.:     12.28b
Issue:          The draft text specifies that "If a duplicate request is
received when pending, the responder may send a duplicate pending immediately,
or continue waiting for its timer to trigger another Transaction Pending".
However, Annex D.1.4 (first paragraph) specifies that "They should send this
[Transaction Pending] response if they receive a repetition of a transaction
that is still being executed."
Proposal:     It is recommended that the text in Section 8.2.3 is at a brought
in line with the text in Annex D.1.4.
Status:
     v13: OPEN. No relevant text changed
     v14: OPEN. No relevant text changed.

 > > v13 Status:     OPEN. No relevant text changed.

v14: SEMI-CLOSED. Text updated to require a final response be sent, however
there's no mention of the sender of the final response indicating that a
confirmation is needed which is needed for correct operation (consider the case
where a single provisional response was issued and lost; the sender of the
final
response is expecting a confirmation which he may never get since the receiver
of the final response has no way of knowing the sender expects it)

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 4 Feb 2000 13:07:52 -0500

There are other messages on the thread.  I'll agree that is would
be good to have 8.2.3 and D.1.4 not conflict, although it is possible
to argue that a specific transport, like UDP can specify some
behavior deemed optional in the main protocol be treated as
required with that specific transport.  In this case, it was
an oversight.

Brian

> From: Chip Sharp [mailto:[email-masked]]
> Sent: Friday, February 04, 2000 12:10 AM
> To: [email-masked]
> Subject: Re: Cisco SG16: Provisional Response timers
>
>