Subject: Re: Issue: Atomicity, batching and config result message

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sun, 19 Dec 2004 18:07:02 -0800

Joel,

I agree with your observations, this has been my experience as well.
However, the protocol provides this flexibility/options for folks who
want to use it. Jamal would probably have some good use cases for this.

regards
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Sunday, December 19, 2004 3:43 PM
To: [email-masked]
Subject: Re: [FORCES] Issue: Atomicity, batching and config result
message

This is an area where I have expressed disagreement in the past, and am 
still quite uncomfortable.
In general, it seems to me that every request should receive an
application 
level response.  (Notifications over a reliable transport are a
different 
matter.)

One can try to construct a case during a multi-request atomic
transaction 
where one would want errors during the transaction, and a success at the
end.
However, in order to perform 2 phase commit, one needs to actively know 
that the first phase has completed successfully.  The lack of a NACK
does 
not constitute sufficient knowledge.
Hence, even in this case I would want individual acks.

Thus, I am left confused (as I was before) as to when a CE could
usefully 
set this to anything other than AckAll.

Yours,
Joel M. Halpern

At 05:52 PM 12/19/2004, Khosravi, Hormuzd M wrote:
>In regards to Config response. It does seem to me to be a source of a
>lot of noise if i have to send back the full message everytime. I
should
>be able to say "I want this config in all-or-none mode and just send me
>a NACK with global reason when a failure happens". This has been
>restricting how we batch in our implementation.
>
>[HK] This is already possible....
>Flags(32 bits):
>   Identified so far:
>   - ACK indicator(2 bit)
>     The description for using the two bits is:
>     'NoACK' (00)
>     'SuccessACK'(01)
>     'UnsuccessACK'(10)->> You can use this Flag in the main header for
>that.
>     'ACKAll' (11)
>
>So I would consider this topic as resolved...the appropriate text needs
>to be supplied to Avri.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 19 Dec 2004 21:49:47 -0500

One of the things the IETF has learned over the years is that options are 
generally a bad thing.
If there really are clear use cases, I am happy to support them.
But unless they can be shown, the flexibility of controllable acks is 
probably a mistake.

Yours,
Joel

---

From: [email-masked]
Date: Mon, 20 Dec 2004 13:27:46 -0500

I thought that the reason for allowing for acks to be suppressed had to 
do with scaling properties on the numbers of FEs that could be 
supported.  So in those cases where there is a reliable transport then 
it seems acceptable to not get Ack on things that succeed, though I do 
believe failures should always be acked.

a.

On 19 dec 2004, at 21.49, Joel M. Halpern wrote:

> One of the things the IETF has learned over the years is that options 
> are generally a bad thing.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 20 Dec 2004 14:20:40 -0500

Given that the CE does not know how long the FE may take to process 
something, how does the CE ever know that it can count on something having 
been done, so that it make decisions that depend upon that.  Should it 
assume that if more than 1 minute has gone my then no error will be 
forthcoming?

Optimistic behavior is fine for some cases.  This does not seem to be one.

And, given that one is keeping the TCP connection open, the cost of 
processing the message is pretty small.  Always ack seems a good trade for 
behavioral and protocol simplicity.

Yours,
Joel

At 01:27 PM 12/20/2004, [email-masked] wrote:
>I thought that the reason for allowing for acks to be suppressed had to do 
>with scaling properties on the numbers of FEs that could be supported.  So 
>in those cases where there is a reliable transport then it seems 
>acceptable to not get Ack on things that succeed, though I do believe 
>failures should always be acked.
>
>a.
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 20 Dec 2004 22:21:39 -0500

> assume that if more than 1 minute has gone my then no error will be 

A unidirectional heartbeat for example doesnt need a response back.
A ping needs a full response  (with data).
A abbreviated ping needs just an ACK back
Timers apply to the last two.
Essentially: Its per desire/app specifics that counts..

> behavioral and protocol simplicity.

I think we should leave the doors open slightly for the methods (the
protocol execution part) as well[1]. I dont think that the schemes for
asking the FE how to execute or report back and format sacrifice the
design or make the protocol a christmas tree. 
I believe that in the end one method may become predominant. So lets
have evolution select the surviving modes. Infact survival may become
apparent after the first implementations show up. In which case we can
kill things before RFC status. As example at the moment we have only
implemented the all-or-none execution and full-report formating mostly
because they appeared to be the safest ones to do (i.e least
controvesial). We may never end up implementing anything else if its not
practically needed. 

I have attached discussion text on this - we can revisit what you have
been saying so far or we could move the text into the draft.

Hormuzd, I have added your pointing of the different ACK modes (that i
somehow missed). Lets get consensus first before we close this issue.
At the rate its going I dont think i would need to add it to the
database.

cheers,
jamal

[1] The "opaquness" of the methods is not mandating they be used. Just like 
the data being operated on being unique to LFBs/apps - I think there may be
specifics that would work only for certain LFBs but not others.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 20 Dec 2004 23:20:13 -0500

The heartbeat is an interesting question.
Also, this perspective changes the question a bit.
What I am looking for is not so much an ack, as a response.
I think that we can define the behavior we want, and not get into a set of 
bits which can be set wrong.

There seem to be three cases covered below:
1) A messages, with an effect, that would not otherwise need a response.
2) A message which gets a response
3) A message wherein the delivery of the message is the goal.

If an ack is defined as ~a response used when one is not defined for the 
message~, then the distinction between two and three goes away.
The heartbeat is harder.  I do note that if there is a response (ack) to 
the heartbeat, then we get an interesting simplification.  Either side 
choosing to drive the heartbeat (or only one doing so) drives heartbeats 
for both sides.
(This does not fit with the view that a heartbeat is an LFB manipulation, 
but then I don't take that view.)

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 21 Dec 2004 06:18:10 -0500

> The heartbeat is an interesting question.

The heartbeat was something i could think of right off the bat - it is 
intended to be motivation that people think differently depending on the
application even for something as simple as a heartbeat. One could look
at the PL protocol as something of an enabler of multiple apps with
slightly varying requirements .....

A variation of the heartbeat for example is: dont ask for a response
back except every 10th time where you request for an ACK only (and in
addition every 20th time you request for a response throw a die and if
the number 6 turns up ask for a full response) etc. I am not sure if i
am making my point clear.

> message~, then the distinction between two and three goes away.

Both 2 and 3 require reliability at the PL layer. 3 requiring more
details. 
Details may be good in validation but consume more bits on the wire. 
In a reliable underlying transport, you may need just a short form of
the truth a "yes all went fine" instead of a "yes, setting of attribute
X on LFB selector Z and deleting entry index 10 of table foot went ok".

Note in the text i attached there is one other mode: "errors only"
Asks to be told only when theres an error that happened.
..
Useful when execution success is certain and reliable delivery.
An example is when you are doing periodic sync updates in which you 
dont care if a message or two get lost. But you care if the update
didnt succeed. 

> but then I don't take that view.)

Refer to my motivation above.

cheers,
jamal