Subject: RE: [GSMP] Bulk Transactions

From: "Anderson, Todd A" <[email-masked]>
Date: Thu, 26 Jun 2003 09:41:04 -0700

At least in the ForCES work, the general consensus is that the controller needs to
be able to say whether a bulk message requires atomicity or not.  In either case,
I think per sub-message error codes are needed.  If atomicity is required you'd
like to know which submessage caused the transaction to fail.  If atomicity is not
required, then you need to know which sub-messages succeeded and which failed.
 
Todd

-----Original Message-----
From: avri [mailto:[email-masked]]
Sent: Thursday, June 26, 2003 4:13 AM
To: [email-masked]
Subject: [GSMP] Bulk Transactions

This mention of bulk messages reminded me that there 

was a requirement: 

2.7.2. Bulk Transactions 

in the requirements draft. 

I have a question about these. 

not about their importance, but about their atomicity. 

Currently we have only one error code in a message. 

So, do we consider a bulk message a single action? 

this would mean that if even one of the transactions failed, 

the entire command would fail. 

in order for state to be determinate, this would mean the 

switch would be responsible for undoing any transaction 

that had been completed. 

Or are we saying that we need for each transaction to be 

an atom it is own right and thus each one will need its own 

error code. 

I tend toward the former, thus placing the burden of being able 

to guarantee to undo any changes on the switch. And if the 

switch is not equipped to do so, it should reject bulk transactions. 

Another questions i have: 

- Do we modify existing messages to support 

bulk transactions or do we create new messages. 

- and if so what needs to be bulk enabled: 

- add is obvious 

- reservation 

- or is the triggered add i wrote about sufficient if 

it has the bulk transaction capability, with an 

individual reservation message needed prior 

to each transaction. 

I tend toward the third possibility. 

Comments on both issues please! 

a. 

On tisdag, jun 24, 2003, at 01:25 Asia/Seoul, Stephen Shew wrote: 

I'm not familiar with the short header work and can't judge its usefulness for burst switching.  Can they be used in a bulk message (multiple adds for example)? 

-----Original Message----- 

From: avri [mailto:[email-masked]] 

Sent: Thursday, June 19, 2003 23:04 

To: [email-masked] 

Subject: [GSMP] Shorter msg for add reservations 

As promised a specific message on header compression. 

On Monday, Jun 16, 2003, at 12:15 Asia/Seoul, avri wrote: 

> - there has been an issue concerning the size of the gsmp message 

> header brought up by the folks working on optical burst switching - i 

> will send a specific message to the list on this issue. 

So, what do people think? 

Should there be a general mechanism inserted similar to the short headers we removed over 2 years ago?  Some new sort of header compression? 

Should there be a new mechanism related solely to reservations. I.e. a new add-reservation message is created that includes only 

[vers, sub, msg type, result, code] 

[partition id, transaction id] 

[reservation id] 

[I, submsg, length]  or is this needed - though we may be able to 

                                use a bulk mechanism for other add-resv 

uses 

anything else?   and is this still too big? 

And does the reservation message need to  changed 

to allow for these complete reservations.  What, if anything needs to be added to the reservation message? 

Opinions?  suggestions? 

Please, speak up. As an editor, I am am working on the 

update for the upcoming meeting at the moment, and need guidance. 

As a co-chair, I would like to know if there is consensus on making such a change. 

I encourage the Optical draft team to discuss their rationale and needs on the list in response to this message. 

a. 

note: since i am functioning as a co-chair and editor, any process issues that may arise from this dual role will be handled by the other co-chair 

_______________________________________________ 

GSMP mailing list 

[email-masked] 

https://www1.ietf.org/mailman/listinfo/gsmp

---

From: "Stephen Shew" <[email-masked]>
Date: Thu, 26 Jun 2003 16:19:22 -0400

I support the atomicity requirement since commands in the bulk message
aren't dependent on each other.  If there are commands that are dependent on
each other then they should be packaged together in some way.  As far as
reporting the results, the single message reply could contain individual
replies for each of the commands.  One reason for the bulk message is to
improve performance while still being subject to the serial transaction
model.  Here, I don't have any dependencies between multiple commands, but
want to send them all at once without having to wait for the response before
sending the next one.
 
I don't have an opinion on the 2nd issue of message design.

-----Original Message-----
From: avri [mailto:[email-masked]] 
Sent: Thursday, June 26, 2003 07:13
To: [email-masked]
Subject: [GSMP] Bulk Transactions

was a requirement: 

2.7.2. Bulk Transactions 

that had been completed. 

error code. 

- add is obvious 

- reservation 

to each transaction. 

a.