[Nsi-wg] tomorrow's NSI conf call
Artur Barczyk
Artur.Barczyk at cern.ch
Wed Jan 19 03:00:33 CST 2011
Hi Inder,
good points, I'll try to answer them, but have only a few minutes
before a meeting...
On 01/19/2011 09:28 AM, Inder Monga wrote:
> Artur,
>
> Thanks for providing an update. I like the two states at the bottom that clarify what happens when the Cancel message is received. I have a few clarifications:
>
> 1. For the last state transitioning from ANY - Canceling - Terminating.
> - Ideally, the intermediate RA would send a Cancel message to the downstream PA and then release the resources and reservation without waiting for a release confirm?
> - Do we really need at the intermediate PA to wait to hear Rel_conf from all the downstream nodes before sending our own?
I think it can be done both ways. If we wait for an explicit
confirmation, we'll need timeouts to guard against failures.
A timeout has to be interpreted as "failed", but there's nothing
else you can do than move to Terminating state anyway.
If we have explicit confirmation, it would be useful for logging
the fact that either the connection was released by the PAs, or not.
Now, that's not a function of the protocol, so I could
see also operation without waiting for confirmation - you send a
cancel/release request, make sure your local resources are released,
and move to terminating state.
It ties in in the discussion what happens if a message is received
from a PA relating to a connection which was already terminated.
I am sure Jerry can tell you the details on the call.
>
> 2. I missed the discussion for the two new states (Auto-start and Idle) - and really did not see this discussion in last week's minutes? Can you provide more insight why these are necessary? I do understand that they may clarify how you would do each feature like auto start vs manual start, but does it really need a different state?
These states are not new. I removed them at some point for comparison,
but on a previous call it was felt they are useful, so here they are
back.
I believe this makes for a better logical split of the state machine
into a part where the connection is "only" scheduled in the future
(red), and where resources are under the control of the RA (blue).
Auto-start (taken the state name from Jerry) is what I considered a
better name for what I was calling scheduled_wait previously.
>
> 3. From the state machine, the only way the circuit will come out of "In Service" state to "Idle" is when RA sends an explicit release message? There is no timer for the aforementioned state transition. Timer expiry is always the expiry of the reservation?
Yes, in this version. As I said, this SM does not handle things like
data plane faults, etc., e.g. reported by PA. Looking back, I had an
initial proposal where it would, but that was put off for later, if
memory serves.
Now, timer indicating end of reservation will bring us into the
terminating state in the end - there's no need to go to idle.
What other timer event would you think of?
>
> 4. Any communication timeout (for example after sending 3 messages or so without getting an ack back) should result in the PA communicating upstream and releasing the connection unless there is a catastrophic failure?
IMO, a communication timeout has to be treated as the PA not being able
to comply with the request.
There's no guarantee even that the remote NSA did receive the request.
(I consider the NSA having received it when the handler dequeues the
request, not when it's hanging in some RX buffer. So in my view
the transport protocol does not guarantee delivery.)
Gonna go, but I hope I could answer some of your points. Discussion
would be much better, of course.
Cheers,
Artur
>
>
> Thanks,
> Inder
>
> On Jan 18, 2011, at 11:55 PM, Artur Barczyk wrote:
>
>> Hi Guy, All,
>>
>> unfortunately I won't be able to attend today's
>> call. For the discussion, I attach the latest state
>> diagram V2, i.e. with the idle state back in.
>>
>> To make the picture clearer, I separated out
>> the transitions due to Cancel request and End of
>> reservation - these can occur from any state, it
>> would just make the picture less readable. Instead,
>> they are shown in the lower part of the diagram as
>> transitions from "Any" state.
>>
>> Jerry, I did not after all include "Init" and "Terminated"
>> states - I'd like to understand better (and discuss) the
>> necessity of these. (Not a silent drop :-) )
>>
>> I apologize I cannot participate in the discussion
>> today, but will be happy to receive comments and
>> read the minutes...
>>
>> Best regards,
>> Artur
>>
>>
>> On 01/18/2011 06:21 PM, Guy Roberts wrote:
>>> Hi all,
>>>
>>>
>>>
>>> The following is dial-in information for Wednesday's NSI call, time:
>>> 7:00 PDT 10:00 EDT, 15:00 GMT, 16:00 CET, 24:00 JST
>>>
>>>
>>>
>>> 1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International
>>> participants dial: Toll Number: 303-248-0285 Or International Toll-Free
>>> Number: http://www.readytalk.com/intl 3. Enter 7-digit access code
>>> 8937606, followed by “#”
>>>
>>>
>>>
>>> Agenda:
>>>
>>> Ongoing NSI protocol and state machine discussion.
>>>
>>>
>>>
>>> Guy
>>>
>>>
>>>
>>>
>>>
>>> _____________________________________________________________________
>>>
>>>
>>>
>>> ** Guy Roberts, PhD Network Engineering & Planning
>>>
>>> * * Tel: +44 (0)1223 371300
>>>
>>> * * City House Direct: +44 (0)1223 371316
>>>
>>> * 126-130 Hills Road Fax: +44 (0)1223 371371
>>>
>>> * Cambridge
>>>
>>> * CB2 1PQ E-mail: guy.roberts at dante.net
>>> <mailto:guy.roberts at dante.org.uk>
>>>
>>> D A N T E United Kingdom WWW: http://www.dante.net
>>>
>>> _____________________________________________________________________
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>
>> --
>> Dr Artur Barczyk
>> California Institute of Technology
>> c/o CERN, 1211 Geneve 23, Switzerland
>> Tel: +41 22 7675801
>> <CS_statemachine V2 20110116.jpg>_______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>
> ---
> Inder Monga
> imonga at es.net
>
>
>
--
Dr Artur Barczyk
California Institute of Technology
c/o CERN, 1211 Geneve 23, Switzerland
Tel: +41 22 7675801
More information about the nsi-wg
mailing list