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

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 26 Sep 2006 20:23:54 +0300 (EEST)

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

---

From: David Palma <[email-masked]>
Date: Tue, 26 Sep 2006 18:54:22 +0100

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

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 26 Sep 2006 21:00:17 +0300 (EEST)

Thanks for the message. That would be the simple solution, true, but I
wonder if people are comfortable with just that. I'd like to hear people's
views on wherther we should go for

A) no RESPONSE messages to errors, no signaling of errors with tearing 
   RESERVEs (just rely on the soft state).

B) Provide something more (as presented in my email).

Regards,
Jukka

On Tue, 26 Sep 2006, David Palma wrote:

> 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,
> > 
> > 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?
> >

---

From: Bernd Schloer <[email-masked]>
Date: Wed, 27 Sep 2006 21:40:58 +0200

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

---

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 28 Sep 2006 09:43:31 +0300 (EEST)

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:

> quite a long time till the soft state expires. This could be a waste of
> resources.
> 
> > 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,
> > > 
> > > 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?
> > >

---

From: Bernd Schloer <[email-masked]>
Date: Thu, 28 Sep 2006 21:07:44 +0200

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 29 Sep 2006 12:14:23 +0200

Hi Jukka

I agree with David that the QNI doesn't need to be concerned with 
reservations that might have not been torn down because they 
will be torn down when the soft state expires.
This holds also for the error codes you listed in your previous e-mail.

Best Regards,
Georgios

-----Original Message-----
From: Jukka MJ Manner [mailto:[email-masked]] 
Sent: donderdag 28 september 2006 8:44
To: Bernd Schloer
Cc: [email-masked]
Subject: Re: [NSIS] A question to people about QoS NSLP Tear operation

Hi,

If you look at the QoS NSLP error situations (codes), all sorts of things
could go wrong, e.g.:

Jukka

On Wed, 27 Sep 2006, Bernd Schloer wrote:

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