Subject: Re: Protocol Operations

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 8 Feb 2005 11:59:45 -0800

Joel, 

I agree with your observations here, Cancel (if we decide to support it)
should probably be new message type in the header itself. Jamal had
introduced this one in the protocol, to support the timeliness
requirement. I don't have strong preferences on this, but want to make
sure we are all on the same page.

What do you guys think about this command ?

Thanks
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, February 08, 2005 11:19 AM
To: [email-masked]
Subject: Re: [FORCES] Protocol Operations

I would expect "cancel" to operate on a request level.  That is, a PDU 
carrying OPERATION TLVs would have an ID of some sort for the whole PDU,

and a Cancel message would use that same overall ID to indicate what was

being cancelled.  That is, "cancel" is at a higher syntactic level than
we 
have been discussing.

As a separate matter, I think that Cancel is likely to be ambiguous in 
effect, so I am not sure that we should try to support it.  The race 
conditions are "interesting".

Yours,
Joel

At 02:02 PM 2/8/2005, Khosravi, Hormuzd M wrote:
>The reason for CANCEL command was basically to nullify or cancel a
>previously configured operation on the FE which is not done in a
certain
>period of time.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 8 Feb 2005 15:10:50 -0500

Kill the CANCEL now that we dont have TCP as the TML imposed on us.
The idea was to cancel a locally or even remotely command stuck on a
retransmit queue (due to TCPs head of line blocking).

cheers,
jamal

---

From: Alistair Munro <[email-masked]>
Date: Tue, 8 Feb 2005 21:42:01 +0000

Hi all,

Going back to earlier messages today, personally, I am happy with GET, SET 
and NOTIFY, or ADD, REPLACE, etc. as top level commands.

Joel wrote recently to answer part of my earlier question about rollback 
(or cancelling), which, as he deduced correctly, was about transaction 
boundaries - i.e. there's no problem provided you know what ID's are being 
rolled back and what operations they refer to.

Given this, if you want to call it CANCEL, that's fine by me - better than 
some of the impenetrable transactional terms. I think I'm agreeing with 
Joel here, although I don't understand where the race arises - with just 
one CE at least, and with more than one, the atomicity/isolation rules are 
intended to avoid such races. But I don't think any scheme would work for 
multiple CEs controlling the same multiple FEs - "interesting" indeed!

The other part of my question, which I didn't make clear, was that, for a 
CE controlling multiple FEs, *any* failure within a [sequence of] 
operations named by the same ID must cause all those operations with that 
ID to be rolled back for all FEs, including those that offered success. 
One-to-one there is no problem.

> [Jamal wrote] Kill the CANCEL now that we dont have TCP as the TML 
imposed on us.
> retransmit queue (due to TCPs head of line blocking).

But I am out of touch here, and apologies if I'm covering old ground. Is 
TCP forbidden? I've used TCP to support this kind of thing and it sure does 
block. However, 2-phase commit is intended to get round this (among other 
failures) in a consistent way, although a severely untimely one in this 
case. The connection must be closed, which will freeze the operations and 
data in progress (isolation) consistently at both ends until the recovery 
or abort phase starts in a new connection. This isn't a transport layer 
issue per se: I think anything that behaved the same way as TCP would have 
a similar problem - any queue can block.

Regards,

Alistair

--
Alistair Munro,
Principal Engineer, U4EA Technologies Ltd.
City Point, Temple Gate, Bristol, BS1 6PL, U.K.
E-mail: [email-masked]
Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile)
+44-7974-922-442;
Fax: +44-117-373-6751
Web: http://www.u4eatech.com

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 8 Feb 2005 18:12:08 -0500

On Tue, 2005-02-08 at 16:42, Alistair Munro wrote:

[I will let Joel respond to that first piece]

> a similar problem - any queue can block.

You are correct there are two levels of blocking: at a message and
transactional level. I was worried about the former. TCP is known to
have HOL issues. Many studies have shown this (so dont ask me to justify
this). Theres one good reason why people end up electing to use SCTP
instead. What i was hoping to achieve when i proposed the CANCEL message
is the idea as described by SCTP in RFC 3758 in regards to timeliness.

So its not exactly 2pc thats at stake here - many fine distributed
databases are known to do 2pc over TCP. Oracle if memory serves right
allows both TCP and UDP as transport (not sure which one it defaults
to). I am hoping not to distract current discussion - this is a valid
discussion but maybe getting into TML land (and i would rather spend
time knocking the big ticket items). 
I apologize in advance if that didnt come out right.

cheers,
jamal

---

From: Alistair Munro <[email-masked]>
Date: Wed, 9 Feb 2005 07:19:11 +0000

Hi Jamal,

> this).

Yes, I'm clear on this myself. I'll check the SCTP approach.

> I am hoping not to distract current discussion - this is a valid

No problem - I don't want to distract people either, but having had CANCEL 
thrown into the mix, I didn't want to let it pass uncommented.

Regards,

Alistair