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

From: Bernd Schloer <[email-masked]>
Date: Wed, 04 Oct 2006 21:00:09 +0200

Hi Jukka,

what if the QNE asks GIST to remove routing state after receiving the RESPONSE
to the tearing RESERVE when requested or directly when no response is requested?

Bernd

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

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

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 4 Oct 2006 22:13:45 +0300 (EEST)

Yes, that is something I was thinking. Still, we have a small performance 
problem if no RESPONSE is requested, but there is an error in the 
processing of a tearing RESERVE.

E.g., we have

QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR

1. QNI asks to remove a reservation, without confirmation
2. QNE1 does that, asks GIST remove the state, and sends the requests to 
   QNE2
3. QNE does the same and sends the message to QNE3
4. QNE3 noticies some error situation, and sends an error message towards 
   the QNI
5. QNE3 still has a GIST MA with QNE2, and QNE3 can send the error to QNE2
6. QNE2 now does not have anymore a GIST MA towards QN1, thus, it needs to 
   set up one
7. In turn QNE1 gets the same problem to reach the QNI.

Thus, phases 6 & 7 get us a performance penalty, but if we consider that a 
tear in the common case does not fail in the middle of the network, then 
we could just follow the procedure above.

Anyway, if people are fine with the above, I'll introduce this 
functionality to the spec. Then we are done with it, and ready for either 
another WGLC, or AD review.

Jukka

On Wed, 4 Oct 2006, Bernd Schloer wrote:

> >    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: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 5 Oct 2006 12:26:34 +0200

Hi Jukka

I think it is a good solution, that solves the discussed requirements.

Best Regards,
Georgios

-----Original Message-----
From: Jukka MJ Manner [mailto:[email-masked]] 
Sent: woensdag 4 oktober 2006 21:14
To: Bernd Schloer
Cc: [email-masked]
Subject: Re: [NSIS] A question to people about QoS NSLP Tear operation

Yes, that is something I was thinking. Still, we have a small performance
problem if no RESPONSE is requested, but there is an error in the processing
of a tearing RESERVE.

E.g., we have

1. QNI asks to remove a reservation, without confirmation 2. QNE1 does that,
asks GIST remove the state, and sends the requests to 
   QNE2
3. QNE does the same and sends the message to QNE3 4. QNE3 noticies some
error situation, and sends an error message towards 
   the QNI
5. QNE3 still has a GIST MA with QNE2, and QNE3 can send the error to QNE2
6. QNE2 now does not have anymore a GIST MA towards QN1, thus, it needs to 
   set up one
7. In turn QNE1 gets the same problem to reach the QNI.

Thus, phases 6 & 7 get us a performance penalty, but if we consider that a
tear in the common case does not fail in the middle of the network, then we
could just follow the procedure above.

Anyway, if people are fine with the above, I'll introduce this functionality
to the spec. Then we are done with it, and ready for either another WGLC, or
AD review.

Jukka

On Wed, 4 Oct 2006, Bernd Schloer wrote:

> Hi Jukka,
> 
> what if the QNE asks GIST to remove routing state after receiving the 
> RESPONSE to the tearing RESERVE when requested or directly when no 
> response is requested?
> 
> Bernd
> 
remove

---

From: Bernd Schloer <[email-masked]>
Date: Thu, 05 Oct 2006 16:50:31 +0200

Is it important to send the error message back to the QNI?  What can the QNI do
QNE2 can't do? It would be more scalable for the network to send the error message
not further than QNE2. The QNI has not requested a confirmation. QNE2 can take
over the role of the QNI and take care about removing state.

Bernd

---

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 5 Oct 2006 20:07:13 +0300 (EEST)

Hi,

Good point, in most cases this would work. And if there is an error the 
previous QNEs did not have, most probably the QNI is not anymore 
able to help either, since it has removed, and lost, all NSLP states it 
had.

Thus, if there is no RII in the tearing RESERVE, any error in the 
processing should be propagated to the previous hop, but not further.

Jukka

On Thu, 5 Oct 2006, Bernd Schloer wrote:

> > >RESPONSE

---

From: Bernd Schloer <[email-masked]>
Date: Thu, 05 Oct 2006 19:23:18 +0200

Sounds good to me.

Bernd

---

From: Jukka MJ Manner <[email-masked]>
Date: Sat, 7 Oct 2006 11:38:56 +0300 (EEST)

Hi all,

Actually the proposed solution will not work. When any QNE gets a tearing 
RESERVE without RII, the QNE accepts it, removes the reservations, and 
sends it further to the next hop. Now, if this next hop gets into an error 
situation, it is basically useless to send an error message even to its 
previous hop (not to mention the QNI), since it has already removed the 
reservation, and its associated state - only GIST MA is probably still 
available, but not QoS NSLP state.

Thus, we seem to have two options:

a) Just note in the spec, that sending error messages related to the 
processing of a tearing RESERVE is uselsss, or

b) define that a QNE SHOULD keep the reservation state for a period of X 
before finally removing the state. This would allow processing of a error 
related to tearing. Still, what could a QNE do different then?

Regards,
Jukka

On Thu, 5 Oct 2006, Bernd Schloer wrote:

> > previous QNEs did not have, most probably the QNI is not anymore able to
> > help either, since it has removed, and lost, all NSLP states it had.
> > 
> > Thus, if there is no RII in the tearing RESERVE, any error in the processing
> > should be propagated to the previous hop, but not further.
> > 
> > Jukka
> > 
> > >Is it important to send the error message back to the QNI?  What can the
> > >QNI
> > >do
> > > >functionality
> > > > > >  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

---

From: "David Palma" <[email-masked]>
Date: Sat, 7 Oct 2006 11:38:54 +0100

Hi Jukka and all,

I agree with everything said in your previous email but would like to ask a
question and suggest some other option.

Regarding the second option, by maintaining the reservation state for a
certain period of time (almost like soft stat on the first option), if there
is no error and the QNI has not included the RII object (it is not mandatory
right?). We will have a waste of resources on every peer except on the QNR
for every successful reservation. 

With the first option we only waste some resources when there is an error
(which is not probable as success) and this waste of resources only affects
the peer that produced the error and forward.

Although the first option still seems to me less wasteful, none of the
options are perfect. From my point of view a mix of the two options would be
perfect.

My proposal is:

If a RESERVE with the TEAR flag set is sent every peer should check for the
presence of the RII object. If this one exists, the state should not be
removed until it receives a successful REPONSE from the QNR (after the
QOSNSLP_RETRY_MAX it stops waiting, and acts accordingly).

If it does not exists the state should be immediately removed and if there
is some kind of error the soft state will take care of removing all the
remaining resources on the path.

I hope that I have understood everything correctly and that my proposal
makes sense to you.

Best Regards,
David Palma

-----Mensagem original-----
De: Jukka MJ Manner [mailto:[email-masked]] 
Enviada: sábado, 7 de Outubro de 2006 9:39
Para: Bernd Schloer
Cc: [email-masked]
Assunto: Re: [NSIS] A question to people about QoS NSLP Tear operation

Hi all,

Regards,
Jukka

> > Thus, if there is no RII in the tearing RESERVE, any error in the
processing
> > >QNE2 can't do? It would be more scalable for the network to send the
error
> > >message
> > >not further than QNE2. The QNI has not requested a confirmation. QNE2
can
> > >take
> > > >6. QNE2 now does not have anymore a GIST MA towards QN1, thus, it
needs
> > > >to
> > > >Thus, phases 6 & 7 get us a performance penalty, but if we consider
that
> > > >a
> > > >to the spec. Then we are done with it, and ready for either another
WGLC,
> > > >or
> > > > >to the tearing RESERVE when requested or directly when no response
is
> > > > >requested?
> > > > >
> > > > >Bernd
> > > > >
> > > > >
> > > > >
> > > > > >3. If either, or both, should be made possible by the spec, how
would
> > > > > >this 
> > > > > >  the QNE do? Re-set up routing state towards the QNI using GIST,
and
> > > > > >  send

-- 

Checked by AVG Free Edition.
Version: 7.1.407 / Virus Database: 268.13.0/465 - Release Date: 06-10-2006

-- 

Checked by AVG Free Edition.
Version: 7.1.407 / Virus Database: 268.13.0/465 - Release Date: 06-10-2006

---

From: Jukka MJ Manner <[email-masked]>
Date: Sat, 7 Oct 2006 19:36:31 +0300 (EEST)

Hi,

That is exactly what I have written in my editor's copy currently. 
Furthermore, I had an idea for a small additional functionality.

When a QNE sends forward a tear, how long should it wait for the RESPONSE 
to come back through towards the QNI? I think we have to have some time 
limit how long we still keep the resources. I was thinking of "one refresh 
interval". At the expiry of the time interval, the QNE will remove the 
reservation. A QNE must also stop sending periodic refresh messages, even 
if one was earlier scheduled to be sent. This should not happen, if we 
consider that proper timer management makes sure that if a node gets any 
RESERVE message, it removes it's pending refresh timer, and possibly 
restart it.

Regards,
Jukka

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sun, 8 Oct 2006 08:11:20 +0200 (MEST)

Hi Jukka

Please note that this waiting time will influence the way of how the
retransmission procedure decribed in Section 5.2.4 QoS-NSLP.
If this waiting time is higher than the variable QOSNSLP_REQUEST_RETRY,
then the QNI will start a retransmission. I think, in case of a Tear
RESERVE, this should not happen.

Best Regards,
Georgios

>> )

---

From: Jukka MJ Manner <[email-masked]>
Date: Sun, 8 Oct 2006 19:08:03 +0300 (EEST)

Right. But still, if the QNI _really_ wants a confirmation, shouldn't it 
be allowed to use retransmissions? It should in my opinion. But then we 
have an issue if the QNI retransmits a tearing RESERVE but some QNEs on 
the path were too eager to remove the reservation.

Thus, the time out for removing a reservation in case an RII was used, 
SHOULD be at least, e.g., twice the QOSNSLP_REQUEST_RETRY value.

Jukka