Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation

From: "Cheng Hong" <[email-masked]>
Date: Fri, 29 Sep 2006 16:59:27 +0800

Hi Jukka and Bernd, and all,

I would agree with Bernd that the explicit signaling is better than soft
state removal. Relying on the soft state removal means the relevant
resources would be kept for the timeout period. This is not desired in
scenarios where mobility and aggregations are involved. 

As already discussed in the Mobility Applicability draft, in the mobile
environment, it is preferred to have explicit tearing of the old states
to avoid double reservations. In certain case, it is even desired to
allow intermediary nodes, e.g. CRN, to trigger the tearing for network
optimization.

Aggregation is another case that prompt removal is important. Aggregated
reservation usually holds much more resources than individual
reservation. Allowing such state to relinquish for the timeout period
would put delay on new reservations' acceptances. And this could again
cause interruptions to seamless transitions.  

Although the soft state guarantees the ultimate removal of the state,
the network will scale much better with the explicit signaling
supported. (Considering there could be thousands of states involved.)
Therefore, signaling of the errors should be supported even for the
teardown case.

cheers

Cheng Hong 

> -----Original Message-----
> From: Bernd Schloer [mailto:[email-masked]] 
> Sent: Friday, September 29, 2006 3:08 AM
> To: Jukka MJ Manner
> Cc: [email-masked]
> Subject: Re: [NSIS] A question to people about QoS NSLP Tear operation
> 
> Hi,
> 
> if a teardown is not possible due to some errors and the QNI 
> gets informed about them, then the errors might be fixed and 
> a clean teardown gets possible.
> 
> I prefer the signaling of errors rather than soft state removal.
> 
> Bernd
> 
> 
> Jukka MJ Manner wrote:
> > Hi,
> > 
> > If you look at the QoS NSLP error situations (codes), all sorts of 
> > things could go wrong, e.g.:
> > 
> > - Informational: unknown bound session ID
> > - Protocol error: all errors are valid
> > - Transient: possibly "RII conflict", "Mismatch synchronization"
> > - Permanent failure: both (some system error, or authorization 
> > failure)
> > 
> > Thus, would it be important to signal those errors to the 
> QNI when a 
> > resource removal failed?
> > 
> > Jukka
> > 
> > On Wed, 27 Sep 2006, Bernd Schloer wrote:
> > 
> > 
> >>Hi Jukka and all,
> >>
> >>I agree with David that the soft state removes a session if 
> it isn't 
> >>refreshed any more. On the other hand it can be of interest 
> for a QNI 
> >>to know immediately about the success of a state removal. 
> It can take 
> >>quite a long time till the soft state expires. This could 
> be a waste 
> >>of resources.
> >>
> >>What error conditions do you have in mind? Do you thing the 
> existing 
> >>teardown is not reliable?
> >>
> >>Bernd
> >>
> >>
> >>
> >>David Palma wrote:
> >>
> >>>Hi Jukka and all,
> >>>
> >>> From my point of view even that the draft recommends to send a 
> >>>RESPONSE message to errors that might occur on a RESERVE with the 
> >>>TEAR flag, like missing QSPEC (if necessary) or if a 
> reservation does 
> >>>not exist (this message might also be silently dropped), 
> this is not necessary.
> >>>
> >>>Even if the RESERVE with the TEAR flag is not accepted, 
> after a while 
> >>>the soft-state will take care of the process of removing 
> this session 
> >>>since it isn't refreshed anymore.
> >>>
> >>>For the same reason I believe that RII is not necessary 
> since the QNI 
> >>>doesn't need to be concerned with reservations that might have not 
> >>>been torn down because they will be when the soft state expires.
> >>>
> >>>Best regards,
> >>>
> >>>David Palma
> >>>
> >>>Jukka MJ Manner wrote:
> >>>
> >>>
> >>>>Hi all,
> >>>>
> >>>>It seems that our spec is not very clear on how Tear-operations 
> >>>>should be handled, or at least leaves some things a bit too open.
> >>>>
> >>>>1. Can a Tear-operation cause an error situation, and 
> cause an error
> >>>>  message to be sent back towards the QNI? Should some errors be 
> >>>>silently
> >>>>  accepted, should the tearing RESERVE still be sent further?
> >>>>
> >>>>2. Can the QNI request a confirmation of state removal, that the 
> >>>>operation was successful, e.g, by including an RII into 
> the tearing RESERVE?
> >>>>
> >>>>3. If either, or both, should be made possible by the spec, how 
> >>>>would this affect GIST? A QNE gets a tearing RESERVE, it 
> removes the 
> >>>>state (1), forwards the message towards the next QNE (2), and may 
> >>>>ask GIST to remove any routing state for this session. 
> Now, if this QNE later gets
> >>>>back an error message, or a RESPONSE, for a session it no 
> longer   knows,
> >>>>what does the QNE do? Re-set up routing state towards the 
> QNI   using
> >>>>GIST, and send the message forward?
> >>>>
> >>>>RSVP RFC2209 says basically that unknown messages are 
> silently dropped.
> >>>>Still, in this case, an error message, or a RESPONSE, can be 
> >>>>considered to be similar to an RSVP CONFIRM (RACK) 
> message, which is 
> >>>>just forwarded without much processing.
> >>>>
> >>>>
> >>>>Regards,
> >>>>Jukka
> >>>>
> >>>>_______________________________________________
> >>>>nsis mailing list
> >>>>[email-masked]
> >>>>https://www1.ietf.org/mailman/listinfo/nsis
> >>>>
> >>>> 
> >>>
> >>>
> >>>_______________________________________________
> >>>nsis mailing list
> >>>[email-masked]
> >>>https://www1.ietf.org/mailman/listinfo/nsis
> >>
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Bernd Schloer <[email-masked]>
Date: Fri, 29 Sep 2006 21:30:09 +0200

Dear Hong and all,

the normal case should be that the teardown is understood,
where possible an error situation should be recovered and
where no recovery is possible the reservation state can be
torn down by the soft state expiration. 

An unrecoverable error could be the wrong SID or the QNI
fails because on an empty battery. I think a confirmation
of state removal improves network scalability.

Bernd

soft state expiry.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 30 Sep 2006 13:01:11 +0200 (MEST)

Hi all

I think that there might be a misunderstanding in the meaning of this
thread.
I think that all of us agree that an explicit tear (release) procedure
must be used. Thus a RESERVE with a Tear (T)  flag set will be used when
an explicit tear (release) procedure is required.

The open issue is related to weather it should be possible for the QNI
(QNE)  to include an RII object in the tear RESERVE in order to
subsequently receive a RESPONSE from the QNR. In this way the QNI (QNE)
will know that the tear down procedure was sucessful.

Best Regards,
Georgios

---

From: Bernd Schloer <[email-masked]>
Date: Sat, 30 Sep 2006 14:37:59 +0200

Hi Georgios,

one question was whether it should be possible to include a RII object
in the teardown msg to get a confirmation of state removal.

Another question was whether a teardown can cause an error situation and
how this error situation is handled. When the Reserve with set T-Flag
is not accepted, an error message could be sent back or the message could
be ignored which causes state removal by soft-state expiration. My idea
then was that the error situation could potentially be fixed when the QNI
gets informed and that for network scalability reasons this should be preferred.

I can't see a misunderstanding so far. Please see also 
http://www1.ietf.org/mail-archive/web/nsis/current/msg06745.html

Best Regards,
Bernd

Georgios Karagiannis wrote:
>>https://www1.ietf.org/mailman/listinfo/nsi
> 
> s

---

From: Bernd Schloer <[email-masked]>
Date: Sat, 30 Sep 2006 18:32:39 +0200

Hi,

the Mobility Applicability draft mentions that after reestablishing NSIS
state along a new path the reservation on the old path needs to be quickly
removed to avoid double reservations and waste of resources. It is recommended
to use teardown messages rather than soft state removal. I believe that
explicit confirmations of state removals and notifications in error cases
support to quickly delete the old state.

The draft also talks about Multihomed mobile environments and about MNs
with multiple interfaces. Multiple interfaces could be used simultaneously
when a handoff occurs to reduce the latency. When using two interfaces,
the second could perform the scanning for new channels in the background
while the first operates normally. The scanning for new channels is quite
time consuming. When scanning, authentication and reassociation is done,
one can switch to the second device.

Is this a possible approach for NSIS mobility or is the MIPv6 Fast Handover
(RFC 4068) more preferred? The disadvantage of the two radio model is the 
higher power consumption for mobile devices. But as long as there are not
continous Ping-Pong handoffs the second device could be used only for
periodic scannings.

Bernd