[Nsi-wg] A alternative Modify() proposal - a "shadow" approach

[Jerry Sobieski]

Hey John-  see notes inline... (thansk for quick response)

On 7/3/12 4:13 PM, John MacAuley wrote:
> Four main points I do not want to lose track of:
>
> 1. The two phase Modify has nothing to do with the type of 
> modification.  I am still hoping to only support bandwidth and endTime 
> modifications for release 2.0.
Right.  I agree.

> The reason we proposed the two phase was because of the complexity of 
> a distributed system and securing resources using the tree model.  If 
> we did a single phase then a modify request would change reservations 
> on the way down the tree, and if a modify failure occurred on a 
> branch, then the only way to restore the schedule to a correct state 
> would be to send down another modify with the original schedule 
> parameters and hope it can be restored.
Ah.  This assumes you do a "modify: that is permanently (.e. unable to 
roll back) each child.   This was not a requirement - this was an 
assumption/design decision you made.   A pathfnder that selects 
resources based on a relationship to the original conenction, but does 
not immediately put them into service is simple.  Our reserve provision 
process does this.  All we need to do is be able to construct a new 
Connection that incorporates the existing resources.   THis is far 
easier than modifying an already cmplex state machine.
> The only solution to this problem is to do the pre-allocation of 
> resources, and once all participants confirm they can meet the need, 
> then we commit the change.
Bingo.  THis is what we do now with the ReserveReq/Confirm process - 
reserve down the tree, confirm up the tree - done.  Followed by the 
provision.  No new state is missing or required.
>
> If we squint our eyes and stand back a bit, we can map two phase 
> modify operations to the existing reservation state machine:
>
> modifyRequest = reserveRequest
> modifyCommitRequest = provisionRequest
> modifyCancelConfirm = terminateRequest
>
> We had looked at overloading the existing reservation operations but 
> it was quickly dismissed as not feasible.
"quickly dismissed as not feasible" ?  It is entirely feasible, and use 
my Shadow proposal as prrof that it is feasible..  Indeed, much more 
feasible than redoing the entire state machine.
> 2. The Modify state machine is separate from the existing reservation 
> and provision lifecycle state machine, and therefore, stands on its 
> own while providing no additional complexity to the existing machine.
Ok.  But our intention is to simplify the state machine - not complexify 
it.   We simply do not need to have two state machines to do this.
>
> 3. I was asked to propose a two phase reserve to fix the original 
> release 1.0 deficiency we introduced for simplicity and to "get 
> something out there".
What deficiency?

> We were lucky with the existing single phase reservation because we 
> get a pseudo commit by having to provision the circuit.
No - we get a real commit by returning a ReservationConfirm()...nothing 
pseudo about it.

> We all agreed to revisit the two phase in release 2.0 so I had no 
> objection to attempt a state machine.  I would rather fix it in 2.0 
> than try to do it in 3.0 and need to support yet another state machine.
I too think we can do this in v2.0, but far simpler than introducing 
these state machine modifications.
>
> It should also be noted that the improved and simplified provisioning 
> state machine is still there as is.  We just expanded the single 
> reserve state into a two phase commit reservation which can stand on 
> its own.  Very elegant if you ask me :-)
We "expanded it" ... unnecessary.   We do things that are necessary - 
not just because they are eligant.   If we need something, then we do 
indeed want an elegant solution.   But an complex and elegant state 
machine does not trump a simple state machine in protocol terms.
>
> 4. Lastly, we need to avoid the pitfall of dropping things just so we 
> can build a demo of release 2.0 for October.  If we can accommodate 
> these features in the specification for release 2.0, then we should 
> and worry about lining up implementations afterwards.
In general I agree. But the manner in which we choose to implement them 
can dictate whether we spend 3 months arguing and rehashing the state 
machine (yet again), or we find a simpler means of doing the same 
thing.    When version 2.0 is ready is a function of what we choose to 
put into it.  And if we decide we need certain features in order to move 
toward production, and other features are less critical, we can 
re-prioritize things to stay on a anticipated schedule.  If "Modify()" 
cuases and explosion of code due to re-designing the state machine, then 
we ought to take it out of v2.0.

> We have done the detailed legwork, and unless there is a fundamental 
> flaw in the concept, I think we need to get it into the specification 
> so we have something useful to put into production.
The fundamental flaw is the complexity.  You are imposing this on every 
user to interact using these new primitives.  When the existing set are 
sufficient.    Just because you worked on the issue (which I apreciate) 
does not mean we accept it.   This is an significantly complex proposal 
that we should not rush it any more than we should rush other features 
to make a deadline.
>
> Of course, if we remove the tree model and use a chain model you get 
> the implicit commit for all your operations.
The tree chain issue again?  Really?   This modify is not a state 
machine issue...its a pathinding and resource allocation issue.   We DO 
NOT NEED to modify the state machine to do this.  If the group wants to 
fine, but it will impose signiicant innecessary complexity on all concerned.
>
> John.
Best regards - and I do aprecitae the amount of work that went into the 
slidedeck.  I just don't agree with it.
Jerry
>
> On 2012-07-03, at 3:09 PM, Jerry Sobieski wrote:
>
>> Hi everyone-
>>
>> The connection modification capability for version 2.0 was initially 
>> presented as a simple enhancement to extend the scheduled end time.  
>> Or perhaps to increase the bandwidth, on an existing reservation.  
>> This was supposed to be a very limited functional tweek for v2.0.
>>
>> But then we decide "hitless" was a requirement;  And then we added 
>> "path preservation" as a requirement.  It was *assumed* that we 
>> needed a unique Modify() primitive to do this...  probably because 
>> prior tools have them...      Suddenly, _/we are re-defining the 
>> entire state machine/_ (yet again), and making it still more complex, 
>> in order to make this "simple" enhancement.
>>
>> This increasing complexity is actually counter to what we were trying 
>> to do in Oxford: to /simplify/ the state machine.  And in general, 
>> counter to good protocol design.  I think the existing state machine 
>> has been thoroughly vetted and is adequate for the protocol, and that 
>> we should consider functions like "Modify" as higher layer constructs 
>> that should be implemented using the existing atomic primitives we 
>> already have.   Things like protection circuits, and diversity 
>> attributes, and the like will all pose similar challenges - and we 
>> cant keep changing the state machine everytime someone has a "simple" 
>> feature they can't live without...
>>
>> Given the developing complexity, we should step back and re-evaluate  
>> a) the urgency for Modify(),   b) the means/scope of implementing it, 
>>   and c) the timeline it will require to "do it properly".
>>
>> I would like to also propose an alternative "shadow" approach to 
>> provide a modify capability in version 2.0:
>>
>> In a shadow approach, we build a simple second "shadow" connection 
>> reservation, and then perform a Release()-Provision() sequence to cut 
>> over to the modified service instance when ready.  This shadow 
>> approach uses only existing protocol primitives and existing state 
>> machine.    (This is similar to John's talk about "bridge and 
>> roll"... but without a bridge:-)
>>
>> Currently, a separate circuit approach like this would require 
>> separate STPs as endpoints for the modified connection reservation.  
>> However, given virtual STPs (e.g. VLANs), a shadow connection would 
>> not *really* need to terminate at the same source or destination STP 
>> to be useful - i.e. the A and Z endpoints of a modified connection 
>> could be different VLANs without imposing any detectable performance 
>> hit on end-to-end data flow (!) - the sending system simply begins 
>> using a new tag when the shadow provisioning is completed.   (This 
>> requires the end systems agents to know this will occur, but, 
>> strictly speaking, this is entirely feasible.)   The shadow path 
>> would likely even be along the same geographic route - i.e. the 
>> packets would transit all the same network infrastructure, just with 
>> different tags.  Given this situation, the need to "modify" an 
>> *existing* connection, particularly with ethernet based STPs, seems 
>> somewhat unnecessary if you can simply request another connection 
>> with the desired new attributes along the same path and start using 
>> it whenever you please...
>>
>> Being pragmatic though, there are many applications that will not be 
>> able to change their termination point, thus the source/destination 
>> STPs should be simultaneously acceptable for both the shadow 
>> connection as well as the working connection.  Likewise, other 
>> resources (say bandwidth) may not be sufficient to reserve a 
>> completely separate upgraded Connection, and so the path finders 
>> ought to be able to "double-book" resources assigned to the working 
>> connection to be used by the shadow connection.  Since the working 
>> conenction and the shadow connection should never both be active, 
>> this double booking will never cause a conflict.  This ability for 
>> shadows to double-book resources of their working counterpart 
>> provides the functionality we initially wanted: simply upgrading the 
>> existing path.
>>
>> We can easily indicate when we wish to create a shadow Reservation 
>> within the existing protocol:  We simply specify an existing 
>> ConnectionID in a Reservation Request.   If the ReservationRequest 
>> specifies an existing Reservation rather than a new Reservation, then 
>> a [new] shadow Reservation/Connection is to be created and linked to 
>> the original "working" reservation.   Thus, an otherwise normal 
>> Connection is identified as a "shadow" connection solely by the link 
>> to a working Connection.    When a reservation is confirmed, if it 
>> links to a working connection, the RA will immediately replace the 
>> working with the shadow and Terminate the working reservation.   In 
>> the one case where the working connection is Active, the shadow will 
>> remain in its Reserved state as if it had passed the start time and 
>> was awaiting a provision request.   When a Release occurs for the 
>> working connection, a check is made to see if a shadow is linked to 
>> it.   If so, the shadow will then replace the working, and the 
>> working connection is Terminated.
>>
>> This process does not change the NSI-CS protocol or the state 
>> machine.  It incur [minor] code additions to the existing primitives, 
>> but does not change the event driven state transitions.  Pathfinders 
>> should to also be enhanced to double-book shadow resources.
>>
>> This "shadow" approach has this major advantage:  Since it is 
>> essentially just building a second reservation, it does not require 
>> changing the fundamental NSI-CS protocol or the state machine.   All 
>> the "modification" processing is implemented using existing 
>> primitives and state transitions.  The cost to the user is minimal: a 
>> single *potential* brief hit as the A and Z endpoints are switched to 
>> the [new/modified] connection.  And since the user initiated the 
>> modify() in the first place, and will need to adjust the behaviour of 
>> the application to take advantage of the new characteristics, it does 
>> not seem unreasonable to expect the user to be able to deal with a 
>> hiccup - if it occurs.
>>
>>
>> Finally, as a general recommendation:  Modifying the existing 
>> primitives and the associated state machine should be a /last/ 
>> resort.  Any new feature should have a very strong case for modifying 
>> the NSI-CS state machine, and alternatives that do not do so should 
>> be strongly encouraged.   We should only modify the NSI core 
>> protocols in order to simplify them, delivering additional features 
>> through higher level service constructs wherever possible.
>>
>> Thoughts?
>> Jerry
>>
>>
>>
>> On 7/2/12 11:06 PM, John MacAuley wrote:
>>> Peoples,
>>>
>>> Here is the new and improved NSI CS state machine fresh off the presses and ready for your viewing pleasure.  Please study it and prepare questions for the Wednesday call.  We would like to close on this action ASAP.
>>>
>>> Thank you,
>>> John.
>>>
>>>
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg at ogf.org
>>> https://www.ogf.org/mailman/listinfo/nsi-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120703/52f31120/attachment-0001.html>