RE: Bulk Transactions

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 protected]]
Sent: Thursday, June 26, 2003 4:13 AM
To: [email protected]
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 protected]] 

Sent: Thursday, June 19, 2003 23:04 

To: [email protected] 

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 protected] 

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