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

From: "Cheng Hong" <[email-masked]>
Date: Mon, 2 Oct 2006 16:33:37 +0800

Hi Bernd,

Please see some comments below:

> 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.

Yes. That is also a reason for me to agree that the notification in
error cases for tearing is desired.

> 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.

Regarding this, I think it is not up to the NSIS WG to decide which
approach is better. Different cases have their own virtues. It probably
depends on the deployment environments, e.g. in 3G system or in general
Internet. For NSIS, the protocol should be designed to support both
cases (unless they conflict with each other). 

As for the FMIP case, I believe the second radio should also be switched
on before the actual path switch? There are quite a few more interesting
issues for using the NSIS with FMIP, but it might not be an appropriate
topic for this thread :)

cheers

Cheng Hong

> -----Original Message-----
> From: Bernd Schloer [mailto:[email-masked]] 
> Sent: Sunday, October 01, 2006 12:33 AM
> To: Cheng Hong
> Cc: Jukka MJ Manner; [email-masked]
> Subject: Re: [NSIS] A question to people about QoS NSLP Tear operation
> 
> 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
> 
> 
> 
> Cheng Hong wrote:
> > 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: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 2 Oct 2006 10:59:24 +0200

Hi Cheng, Bernd and Jukka

I think Bernd and Cheng are right!
The chocice depends on the deployment environments, e.g. in 3G 
system or in general Internet. For NSIS, the protocol should be 
designed to support both cases (unless they conflict with each other). 

Best regards,
Georgios

-----Original Message-----
From: Cheng Hong [mailto:[email-masked]] 
Sent: maandag 2 oktober 2006 10:34
To: Bernd Schloer
Cc: Jukka MJ Manner; [email-masked]
Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation

Hi Bernd,

Please see some comments below:

> 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.

Yes. That is also a reason for me to agree that the notification in error
cases for tearing is desired.

> 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.

Regarding this, I think it is not up to the NSIS WG to decide which approach
is better. Different cases have their own virtues. It probably depends on
the deployment environments, e.g. in 3G system or in general Internet. For
NSIS, the protocol should be designed to support both cases (unless they
conflict with each other). 

As for the FMIP case, I believe the second radio should also be switched on
before the actual path switch? There are quite a few more interesting issues
for using the NSIS with FMIP, but it might not be an appropriate topic for
this thread :)

cheers

Cheng Hong

> 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
> 
> 
> 
> Cheng Hong wrote:

---

From: "Roy, Radhika R." <[email-masked]>
Date: Mon, 2 Oct 2006 10:29:30 -0400

Folks:

No matter what the implementation modes are there, the Interworking
needs to be there. Let me provide some examples as follows:

1. 3GPP Wireless access networks + IP backbone network (DiffServ, MPLS
DSTE QOS, Y.xxx QOS, and/or others).

2. IP access networks (RSVP) + IP backbone network (DiffServ, MPLS DSTE
QOS, Y.xxx QOS, and/or others).

You may end-up, for example, Interworking with DSTE QOS and Y.xxx QOS
and other Interworking QOS scenarios.

One-way of avoiding this Interworking is to delete those unnecessary
things for which Interworking in QOS is not possible, for example,
so-called DSTE and Y.xxxx specific QOS classes.

Another alternative is to provide clear implementation directions where
and how Interworking in QOS problems can be avoided in these messy
environments.

Best regards,
RAdhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Georgios Karagiannis
Sent: Monday, October 02, 2006 4:59 AM
To: 'Cheng Hong'; 'Bernd Schloer'
Cc: 'Jukka MJ Manner'; [email-masked]
Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation

Best regards,
Georgios

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 3 Oct 2006 09:47:01 +0300 (EEST)

Roy,

I don't really follow what you are saying. Should the QoS NSLP have an
explicit tear down confirmation and error signaling, or not? If it should have,
how would it work considering that NSLP and GIST states are removed as the
tearing RESERVE goes through the network.

Furthermore, note that currently we only support a tear-down initiated by 
the QNI. No other node can tear down a reservation on behalf of the QNI.

Regards,
Jukka

---

From: "Roy, Radhika R." <[email-masked]>
Date: Tue, 3 Oct 2006 09:42:03 -0400

Jukka:

I am saying with respect QSPEC that will be used.

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, October 03, 2006 2:47 AM
To: Roy, Radhika R.
Cc: [email-masked]
Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation

Roy,

I don't really follow what you are saying. Should the QoS NSLP have an
explicit tear down confirmation and error signaling, or not? If it
should have,
how would it work considering that NSLP and GIST states are removed as
the
tearing RESERVE goes through the network.

Furthermore, note that currently we only support a tear-down initiated
by 
the QNI. No other node can tear down a reservation on behalf of the QNI.

Regards,
Jukka