[GSMP] Bulk Transactions

[avri <[e-mail]>]

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:[e-mail]]
> Sent: Thursday, June 19, 2003 23:04
> To: [e-mail]
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/gsmp
>